-
设计见 docs/done/system-design/28-agent-registry-unification.md。 改造前 Agent 本体散在三处(system/agents/ 11 个、system/templates/ 50 个、 data/companies/{id}/agents/ 17 个),同一个 AgentScaffold 被三个 baseDir 实例化。 后果是同一角色在 N 家公司下有 N 份互不相干的副本,模板更新不会同步; org-coder / org-planner 这类走 hireFromBaseMetaAgent 造出来的本体 legacy_path 指回自己公司目录,永远无法被第二家公司复用。 本次: - G1 单一注册表:system/templates/ 整体并入 system/agents/,base → _base。 7 个同名 id 逐个裁决,被丢弃的一份归档到 docs/_archive/ 而非删除。 source_kind(template/global_agent/company_hired) → origin(builtin/created)。 - G2 运行态下沉:CLI 的 cwd 从本体根改为 system/agents/{aid}/{cid}/{taskId}/。 memory / conversations 落公司态 {aid}/{cid}/,按公司隔离不串。 sessionPool 的 key 含 (companyId, taskId),两家公司调同一 agent 不复用会话。 - G2b 产物不下沉:交付物仍落 data/companies/{cid}/,system/agents/ 只留运行痕迹。 写入边界按链路分叉——graph 节点走节点私有目录(被 indexNodeOutputs 索引), chat 走公司 workspace,同一提示词里不再出现两条互斥指令。 - G3 公司只存引用:data/companies/{id}/agents/ 删除,新增 company_agents 关联表。 不复用 org_graph_nodes——后者是执行流图,work 层本体被雇时不写它,天生覆盖不全。 - G4 缺则创建:本体缺失时从 _base 复制骨架进 system/agents/{id}/, agent-creator 填 agent.md/soul.md 后才从 draft 转 active(哨兵判据, 骨架未填时哨兵仍在,不许被 hire)。产物即刻是全系统可复用的本体。 新增 server/services/agent-locator.js 收编原先散在 6 处的寻址逻辑。 边界守卫(graph-engine)的豁免从「本体根上五个文件名」放宽为整棵 system/agents/: 新本体的骨架本来就要进 git,gitignore 挡不住 ?? system/agents/{newId}/, 旧判据会把一个真正成功的招聘节点判成 boundary_escape fail。 存量迁移见 scripts/migrate-agent-registry.js(幂等,备份到 data/_migration-backup-*)。 真 Claude CLI E2E 已验证:新建公司 → orggraph-planning 自动规划 → 自动招聘 org-planner/org-coder/org-validator 三节点流水线; data/companies/{cid}/agents/ 不存在,company_agents 4 行, system_agents 56→56(零新建私有本体,纯复用),git status 零增量。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
测试 786/786 全绿(76 文件,起点 760/72),未改任何既有断言。 ## 本轮三件新东西,全部经真 CLI 验证 W12 补完 · 失败原因四环打通 - 引擎自判的失败(executor 抛异常、边界越界、子 run 无归因)现在也落 graph_run_nodes.fail_reason,不再只有 agent 归因产出的才有值 - 概览 tab 展示「[引擎判定] boundary_escape」+ 终端样式 excerpt, 取不到 fail_reason 时回落 output_excerpt,并标明来源 - 真跑实查:两行 fail_reason='boundary_escape' 都在库里, 产生→传递→落库→读回四环在真 CLI 下走通 W13 · 运行态文件根治(守卫误判的根因) - 17 个 todo.md / plan.md / scheduled_tasks.json git rm --cached + gitignore; 源码(agent.md/config.json/soul.md/tools.md)一个未碰,模板本体仍跟踪 - _registry.json 的 usedCount 挪进已忽略的 data/template-usage.json - 真跑验收:整轮(agent-creator、Master 各一次真 CLI、3 次 hire)结束时 worktree git status 与基线逐字相同,_registry.json 零 diff 单步进度感 · 真 CLI 一个节点 3-7 分钟 - 画布卡片秒表 + 详情面板常驻条「运行中 2m40s · 最近事件 …(2m40s 前)」 - 不做假进度条:引擎不知道 agent 还要多久 - 顺手修 NodeDetailPanel 不跟 SSE 走(否则秒表也不会动) W9 失败上下文进提示词、W10 跨层地址两半、W11 Hot Swap 显式告警同批完成。 ## 真跑结论:链路更长,但「work 节点 → success」仍未跑到 走到:orggraph-planning 落图自雇 → agent-creator 补定义 → workgraph-planning 真跑规划 + **先雇后提交**(W5/W6 再次成立)→ 子 run 起来 → work 节点 RUNNING → 7m19s 后 fail。两层原因叠加,都与 W1-W14 无关: 1. **新缺陷**:agent-manager.js:324 把 idleTimeoutMs 硬编码 120s, readme-writer 通读源码静默超 2 分钟被掐死(动笔前就死了)。 同进程 ClaudeCliProtocol 早把自己的 idle 上限放到 24h, stream-executor 的 JSDoc 默认值写的是 30 分钟 —— 这里把两者都压掉一个数量级; 且 ...options 透传的 idleTimeoutMs 会被下一行覆盖,调用方无法覆写。 2. **并行 agent 污染**:retrain-watchdog 每 5 分钟唤起的 Master 在同一工作树里 改了两个源文件,被守卫 git status 差集算到该节点头上 → 额外署 boundary_escape。 这是 W3「拦不住」第 5 条第一次真实发生。 顺带记一笔:这一轮任务是 **LemonBoss 自己的 Master 自主下的单**, 走的正是 POST /api/company/:id/tasks,它还自行诊断出了上面那个 idle timeout 并动手改(引用了未定义的常量,是坏的)。 ## 已知未修(下一轮) - idleTimeoutMs 硬编码 120s —— 「work 节点 → success」跑不通的唯一技术原因 - W7 在**零边最小图**上失效:判据③要求存在 active org_graph_edges, 零边图上三条判据全落空,work 层本体被写进 org_graph_nodes。 服务层那 9 例测试造的都是有边的成型图,正好绕开这个形状 - 前端 ACTIVE_RUN 含 blocked、后端 ACTIVE_ROOT_RUN_STATUS 不含: 一家公司只要失败过一次,控制台上就再也下不了第二个任务(后端其实放行) - 真跑期间工作树里不能有第二个 agent 活动,否则守卫判罚不可信 —— 应写进真跑规程 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>