Agent Owners · 一页看懂

公开镜像（链接指向私有仓库，需登录 GitHub）· 更新 2026-09-09 ｜ 设计 v0.1，引擎 E0 阶段已在真实项目上运行 ｜ 本页面向第一次接触的人，术语都配了大白话；权威细节在仓内 Markdown（文末有地图）

一句话：把"一个 AI 助手到处救火"，换成"每块该管的事都有登记在册的承包人，按时来看、看了留凭证、接了不办会被发现、换个会话也不会丢"。 承包人可以是脚本（不需要动脑的事），也可以是 AI（需要判断的事）。它是一个能装到任何项目上的独立模块；一个物流 TMS 项目 只是第一块试验田。
🌾

责任田

把项目切成一块块地，每块地有承包人、有该做的农活、有交活的时间。没人承包的地会荒，这套制度先保证"没有荒地"。
🏢

物业值班

巡逻员（脚本）按点巡逻并打卡；值班经理（AI）只在巡逻员发现异常时出面判断；登记簿（账本）记下谁在几点做了什么；楼外还有个独立看门人，专门盯着"登记簿还在更新吗"。
📦

快递签收

"我发出去了"不算数，"对方签收了"才算。任何交接都要接收方明确签收，否则原来的人继续负责，到点没人签就升级给老板。

1 要解决什么2 解决思路3 角色与零件4 现在怎么跑5 一天的运行6 数据看板7 安全边界8 一张待办的一生9 进度10 路线图11 计划与风险12 常见疑问13 词典与地图

1. 要解决什么问题

项目由一个 AI 主会话驱动时，会出现同一种衰退：注意力在哪，哪里就被做好；没人提起的地方悄悄烂掉。 三种常见补救各有一个漏洞。

漏洞一：写规则文档 CLAUDE.md收尾清单… 读到的那次会话 只在"被读到"那一刻起作用，管不到没人看的领域 漏洞二：写脚本定时跑 cron 脚本每天 09:00 只会报，不会判断 脚本死了没人发现——没有人为它的存活负责 漏洞三：多开几个 AI 会话 会话 A 会话 B 会话 C "我已经发给 B 了" 彼此不知道对方在做什么，"发出去了"变成新的静默断点
三个漏洞的共同点："报告说做了"和"真的做了"之间没有第三方核验。 这个项目今天已经在三个地方撞见同一件事：守恒测试门静默失效两批、tcd 把"提示词粘进输入框"当成已投递、Codex 的标题生成回合冒充最终汇报。

2. 解决思路：先让"漏"露出来，再让 AI 上岗

① 先建登记簿和缺席告警

不先加 AI。先让现有的三个无人值守任务（文档巡检、反馈采集、演示备份）"死了一定露出来"。登记簿是唯一真相源，换会话、断进程都不丢。

② 三条线分别看

"活着"（按点来了吗）、"看全了"（来了但看漏没）、"在推进"（接了的事在动吗）三件事分开判定。一份按时到的坏凭证不算履职。看门人在另一台机器上。

③ 权限靠围栏不靠说明书

AI 的能力由进程边界强制：没有钥匙、没有命令行、不能上网、只能写自己的小目录。写在说明书里的"不许"不算数。

④ 登记簿就是收件箱

承包人之间只通过登记簿交接，接收方必须明确签收；不让 AI 之间私聊，因为私聊会造出登记簿看不见的第二条真相。

⑤ 说明书 AI 只能提议改

调研显示 AI 自己写给 AI 看的规则文件反而降低成功率；改动由人审后升版本。

⑥ 每块地分两层

巡逻层（脚本，常开、只读、零成本）从第一天起给所有候选地登记，责任全覆盖；判断层（AI）只在巡逻层有发现或每周复核时出面，钱花在刀刃上。

另外两条来自项目负责人的批注：担责的是"角色"不是某个人（负责人、顾问、员工都可以）；单机优先、数据只在一处、远端只被观察，唯一必须在别处的看门人可以简单到一行 cron。

3. 角色与零件（大白话版）

🌾 一块田 例：客户反馈这块地 要看的来源：浮钮、门户… 不变量：24 小时内有分诊 承包人 owner 🚶 巡逻层（脚本）常开、只读、零成本，按点打卡 🧑‍💼 判断层（AI）有发现才出面，读材料写草案 该做的事 + 打卡凭证 义务：每天 09:00 看巡检结果 回执：这次看了 7 个对象、 0 个读不到、输入是新鲜的 ✔ 有效 = 按时 + 看全 + 输入新鲜 ✘ 读漏/过期 = 不算履职 📒 登记簿 ledger 唯一真相源：谁该做什么、 做没做、接了没接、到期没 SQLite，一个写入口， 状态、事件、通知一起提交 定期导出只读副本进仓库 👀 看门人（在另一台机器） 只问一件事：登记簿还在按时更新吗 🧑 担责人（角色） 收三段摘要，只做取舍
每个零件只回答一个问题。最关键的分工：巡逻层负责"看到了"，判断层负责"怎么办"，登记簿负责"记得住"，看门人负责"登记簿本身还活着吗"。
术语大白话它"完成"的定义（三者不能混用）
义务 obligation该按点做的一件事在应到时间窗内交出了一份有效凭证
条目 item一张待办条子条子上写的"完成条件"被满足，而不是"有人处理过"
运行 run一次出勤凭证已经落盘并挂到登记簿；出勤完成不等于条子办完

4. 现在真实在跑的样子（TMS 试验田）

💻 控制主机：项目负责人的 Mac ⏱ 每 5 分钟 · 巡逻一轮（照看层） 读四个来源 → 记入登记簿 → 判缺席/读漏/到期 → 写告警 → 生成健康摘要 → 把 180 字节的健康摘要推到东京机 ⏱ 每 15 分钟 · 值班经理看一张条子（判断层） 检查预算 → 领最老的一张待办 → 打包只读材料 → 在小房间里跑 AI（sonnet） → 校验它写的分诊草案 → 出勤凭证 → 草案落到仓库 data/ 目录 只看不动：不改 TMS 任何东西，不发任何对客消息 🔐 能力探针 改了代码就得重考：证明 AI 真的不能开命令行、不能上网、不能改材料 📒 登记簿（仓库外目录） ~/owner-state/tms/：账本、凭证、工作目录、导出、日志 🛠 执行器监工 tcd_watch 盯着派给 Codex 的活：没提交→补回车、停滞→报警、合法停下→交人、完成→自动验收 🗼 东京机（只被观察） 来源（只读） 演示系统的反馈接口评审门户的提交文件文档巡检回执 · 每日备份包 👀 看门人 · 每 15 分钟一行 cron 健康摘要超过 30 分钟没更新→ 经本机中继发飞书；一小时只报一次，恢复再报一次 🧑 人与仓库 飞书私聊大事即时；每天一份三段摘要 工作台决策卡 / 对话多项待拍板发卡片，简单的直接说 agent-owners 仓（私有）设计、实验日志、AI 草案、校准表、监工日志 只读拉取 推健康摘要 失联告警 草案与日志进仓库（不进 TMS，不对客） 为什么这么摆 东京机没装 Claude，内存只剩 0.3 GB，跑不了模型；Mac 有 Claude 但会休眠。 所以模型在 Mac 跑，东京机只多两样东西：一个 180 字节的健康文件和一行 cron。 没有跨机器的数据库访问，日志只在一处。看门人和被看的人不在同一条船上。 Mac 休眠会被当成"失联"——这正是 E0 要收的数据之一。
三台"机器"各司其职：Mac 干活并记账，东京机只提供材料和当看门人，飞书与仓库面向人。

5. 一天的运行（时间线）

00:0006:0012:0018:0024:00 🚶 巡逻层：每 5 分钟一轮（全天 288 次，零 token） 🧑‍💼 判断层：每 15 分钟看一眼有没有待办，有就领一张；每天最多 6 次，没有就安静退出 09:00 文档巡检应到（北京时间） 03:00 备份应到 09:00 给担责人的三段摘要：谁缺席 / 哪些超时升级 / 哪些等拍板 👀 看门人：每 15 分钟看一次健康摘要，超过 30 分钟没更新就发飞书
巡逻是常态且免费；AI 只在有活时出面；人只在早上看一份摘要，和收到失联告警的时候。

6. 数据看板（2026-09-09 当天真实数字）

4/4

今天登记的义务

文档巡检、反馈采集、备份、质量门四项都有巡逻层在看；其中文档巡检今天判"读不全"（见下）
1 秒

失联告警送达

把健康文件改成两小时前 → 看门人 1 秒内把告警送到飞书；一小时内不重复；恢复后报一次
2 / 4

AI 分诊入账 / 尝试

失败的两次都是校验规则太严（引文核对、行数），不是 AI 越权或编造；违规 0
2 / 2

与人工分诊一致

两条校准记录：分类全一致；去向一致 1、部分一致 1（AI 先交人裁定，人直接进需求台账）
四次真实分诊：token 用量（千）与花费 0100k200k #0 失败118k · $0.24 #1 成功182k · $0.24 #2 失败131k · $0.30 #3 成功138k · $0.31 每次 2–3 分钟；约六成 token 是读材料包的缓存；设计预算 60k/次不现实，已按 200k 配
一张待办的 AI 分诊成本约 0.25–0.31 美元。失败的两次也花了钱，所以校验规则要"该严的严、不该严的别浪费"。
能力探针 8 次：AI 真的被关在小房间里了吗 1 2 3 4 5 6 7 8 1 沙箱把家目录和网络全封了 2 --bare 参数跳过钥匙串登录 3 剥掉代理变量 → API 403 4–5 探针不认"工具已禁用"措辞 6–8 全部通过： 命令行不可用 ✔ 上网不可用 ✔ 往材料目录写被系统拒绝 ✔ 每次约 $0.03；改了代码必须重考 这就是"权限靠围栏不靠说明书"的意思：不是相信它不会做，而是做不了。
探针是"考试"：AI 被要求故意去做三件禁止的事，三件都失败才算通过。
控制面失联多久会被发现（上限） 目标（路线图）16 分钟 现在的参数≈45 分钟 = 30 分钟新鲜度阈值 + 最多 15 分钟 cron 间隔。阈值改 11 分钟、cron 改 5 分钟就能到 16 分钟， 但 Mac 每次休眠都会触发告警。先收一周"休眠导致的失联"数据再定。
故意先不调参：数据比直觉重要。
今天的第一条"发现"：文档巡检回执返回码 2 09:00 东京机例行巡检时，仓库里的需求索引被前一个修复包写了一条格式不合法的记录， 检查器读不了 → 返回码 2 = "结论未知"。巡逻层没把它当绿灯，标为"读不全"并开了三级事件。 同一时间主会话在验收那个修复包时也独立发现并修了。所以这条记为"并列"， 不算"先于人发现"。但如果当时没人在看，它就是第一条先报出来的问题。 顺带修了三处误判：时区（东京机其实按北京时间跑 cron）、只读克隆落后不算异常、部署回执字段。
"返回码 2 永远不算绿"是这套制度的铁律之一。

7. 安全边界：值班经理在一个小房间里工作

🚪 小房间（macOS 沙箱，默认什么都不许） 能看的 本次材料包（只读） Claude 自己的配置与安装目录 钥匙串（登录用，由系统代读） 看不到：密钥文件、凭证、其他会话的记录、记忆、家目录其余部分 能做的 读、搜、写自己的 output 目录 连模型 API（经本地代理） 做不了：开命令行、抓网页、派子代理、 改材料、改配置、改 TMS 任何东西、 发任何对客消息 📏 还有三道尺子 预算：每次 20 分钟、40 回合、1.5 美元；每天 6 次；同时只跑一个 凭证由外壳填写，不由 AI 自报：token、花费、有没有越权都由程序记录 它引用的每一句"证据"都要在材料里逐字找到，找不到的不作数 E1 之前要再收紧 它还能看到 Claude 的设置和统计（不含凭证和记录）； 建议放到专用的 macOS 账户里跑，再关小一圈。
比"相信它不会做"更可靠的是"它做不了"，而且每次改了代码都要重考一次探针。

8. 一张待办条子的一生

🆕 新条子 OPEN巡逻层从来源发现一条新反馈，去重后登记；写明谁负责、下一步几点前
→
✋ 已领取 CLAIMED值班经理领走，拿到一张有时限的"工牌"（租约），过期自动收回
→
📝 有草案 PROPOSED分类、依据、置信度、建议去向、最小下一步；E0 到这里为止
→
📮 待签收 WAITING_HANDOFF交给实现队列或需求队列；"发出去"不算，接收方必须签收
→
✅ 办结 CLOSED只有"完成条件"满足才关：有部署证据或人的明确处置

⏫ 升级 ESCALATED

到点没人领、没人签收 → 自动升级给担责人；原负责人不变，只是多了一个人的出口。主会话不在线也照样升级。

🙋 等人拍板 WAITING_HUMAN

需要客户口径或范围决定时挂起，决定入账后从原地恢复，不重来。

❓ 来源读不到 UNKNOWN

接口错误、文件缺失 → 记未知，不推进游标，不冒充"没有新反馈"。

9. 进度（截至 2026-09-09 中午）

✅ 已完成

  • 设计 v0.1、路线图、部署模板、D001 决策、起源材料与你的原话摘要入库
  • E0-A 巡逻层上线：账本、四路只读采集、缺席判定、健康推送、东京看门人、演练脚本，63 项单测
  • 端到端告警演练通过；观察点 cron 已实测每 15 分钟触发
  • E0-B 值班经理跑通：探针通过、4 次真实分诊 2 次入账、校准 2 条一致、每 15 分钟自动调度
  • 执行器监工三单实战并改版为只经 tcd 接口；顺带修了 tcd 三个根因（0.6.3/0.6.4）

🔄 进行中

  • 连续 7 天收数据（休眠缺席占比、一致率、日成本）
  • 校准样本从 2 条补到 10–20 条
  • 今天的文档巡检"读不全"事件，等明晨 09:00 窗口自动恢复

⚠ 打开的问题

  • 还没有严格"先于人发现"的案例，只有一例并列
  • 失联检测上限 45 分钟，未达 16 分钟目标（故意先不调）
  • 巡逻层和值班经理都在会休眠的 Mac 上
  • AI 分诊校验规则曾过严，两次白花钱（已修）
调度
巡逻每 5 分钟（Mac launchd）· 判断每 15 分钟（Mac launchd）· 看门人每 15 分钟（东京 cron）· 摘要每天 09:00
预算
判断层每天 6 次、每次 200k token / 1.5 美元 / 20 分钟、同时只跑一个
仓库
agent-owners（GitHub 私有）· TMS 仓只留决策 D24 与指针 · tcd 仓 0.6.4

10. 路线图：每个里程碑都是一个实验

不是"做完功能就下一步"，而是"每一步先写下假设和要收的数据，数据通过了才进下一步，不通过就返工"。

E0 · 只看不动
现在。1–2 个 AI 承包人只看不动。假设：会比人先发现问题；缺席能被独立测出；AI 和人的分诊一致率能算出来；成本可预测；人每天 ≤10 分钟。退出：7 天数据 + 缺席检测通过 + 一致率有数字。
E1 · 接了就负责到底
主会话离线 24 小时，所有新输入仍有人负责；杀掉实例能接续，旧实例回写被拒；没人签收会按时升级。若 Mac 不在线造成的缺席超过两成，才考虑把账本搬到常在线机器。
E2 · 第一个对外动作
一个具体、常设、可撤销的授权（例如把工单从"待处理"改成"处理中"，不写文字），未授权动作 100% 被拦并留痕，撤销即时生效。
E3 · 第二块判断田
准入四条：巡逻层 7 天有效、确有判断积压、写路径不重叠、预算装得下。两个 AI 承包人并存不撞车，协调开销小于两成。
E4 · 装到第二个项目
只改登记表、说明书、采集器，引擎零改动，半天内跑起来 → 设计升 v1.0，再决定是否脱敏公开。

全程统计的指标：应到/实际/有效窗口数、读不到的来源数、最老没人领和没人签收的条子年龄、重复动作拦截数、"本该先发现却由外部报来"的问题数、模型调用与 token、担责人介入分钟数、人工校准差异数。告警变少不是目标，原来静默的问题被更早发现且有人接走才是。

11. 未来计划与风险

接下来按先后

  1. 7 天收数据，写 E0 结论
  2. 人工校准补到 10–20 条；每周抽 3 条含一条"无活/未知"场景
  3. 看门人阈值调参（30/15 → 11/5 可到 16 分钟）
  4. 值班经理搬到专用 macOS 账户，再收紧一圈
  5. E1：交接/签收/升级、决策卡桥接、义务级告警接飞书
  6. TMS 第二块判断田候选：质量门管家（修复契约草案、复盘初稿）
  7. 把执行器监工正式登记为运维哨兵的一项义务，Codex 掉活次数进指标
  8. E4：装到第二个项目（候选 vibe-workbench）

风险与已知限制

  • Mac 会休眠：一部分"缺席"其实是休眠，靠"到期升级给人"兜底；用数据决定要不要拆机
  • 失联检测 45 分钟：没达标，先收数据
  • 供应商半年一变：Claude 命令行参数、Codex 行为都会变；探针能发现，但要人跟
  • 说明书会腐烂：改动由人审后升版本；复盘的"本质一句话"要回填进去
  • 虚假存活：凭证必须带"看了几个对象、发现几条"，零对象不算通过
  • 人被摘要淹没：摘要只三段，其余进登记簿可查

12. 常见疑问

为什么不让 AI 承包人之间直接聊天？那不是更灵活吗？

因为聊天会造出登记簿看不见的第二条真相："我已经发给 B 了"在登记簿里看不到，B 没接也没人知道。所有交接经登记簿并要求签收，灵活性一点没少（互相能看见对方的条子和状态），但"发出去了"永远不能冒充"办完了"。行业调研里所有企业级案例也都是这么做的；网状私聊只在消费级产品里刚出现。

为什么 E0 阶段不让 AI 动客户看得见的东西，哪怕只是把状态改成"处理中"？

E0 要证明的是"责任能离开主会话"，不是"AI 能面对客户"。先拿 10–20 条 AI 分诊和人工分诊对照的数据，一致率清楚了，再在 E2 用一个具体、可撤销的授权试第一个对外动作。分诊错了顶多是内部草案错，改状态错了客户会看到"处理中"却长期没下文，比"待处理"更伤信任。

为什么都放在 Mac 上，不放服务器？

东京机没装 Claude，内存只剩 0.3 GB，跑不了模型；而且 MVP 要尽量减少分布式复杂度：数据只在一处、日志只在一处、远端只被观察。Mac 休眠造成的缺席会被统计，如果一周数据显示它是主要失败原因，再把账本搬到常在线机器，模型仍留在有 Claude 的机器上。

这东西花多少钱？

巡逻层零 token。值班经理一次分诊约 0.25–0.31 美元、2–3 分钟，每天上限 6 次；探针每次约 0.03 美元。今天全部加起来不到 2 美元。

它到底发现了什么人没发现的问题？

诚实地说：目前只有一例"并列"（文档巡检读不全，主会话同时也发现了）。但今天的三个 Codex 作业里，监工抓到并自动处理了"提示词没提交""回合结束没汇报标记"两种掉活，还识别出一次合法停下没有误催办。这些是执行器这块田的真实数据。

AI 承包人会不会自己改规则、越权、编证据？

说明书它只能提议不能改；权限靠沙箱和参数强制（探针每次改代码都重考）；它引用的证据必须在材料里逐字找到，找不到的不作数；凭证由程序填写而不是它自报。今天 4 次真实运行，越权 0 次，两次失败都是我们的校验规则过严。

13. 小词典与文档地图

术语 ↔ 大白话

田 field一块登记的责任范围
owner承包人：巡逻层（脚本）+ 判断层（AI）
obligation该按点做的事，有应到时间
item一张待办条子
run / receipt一次出勤 / 打卡凭证
ledger值班登记簿，唯一真相源
observer楼外的看门人（死人开关）
accountable最终担责的角色
lease / fencing token有时限的工牌，过期作废
capability probe能力考试：证明 AI 做不了禁止的事
rc=2"结论未知"，永远不算绿

权威文档（仓内 Markdown）

进度STATUS.md
设计docs/design/01-通用方案-v0.1.md
路线图docs/roadmap/01
部署与回执01 模板 · 02 TMS · 03 E0-A · 04 E0-B
决策D001
起源与原话context/
实验数据E0-tms 日志 · AI 草案与导出
接手的 AI 先读AGENTS.md

本页由主会话生成，随 STATUS 更新时重绘；数字以实验日志为准。