# 30-task-delegation-reliability-gaps. 任务委派可靠性现状 —— 已确认的鸿沟清单

> **日期**: 2026-08-21
> **性质**: 现状调研记录，不是设计方案。列的是「代码现在长什么样、缺什么」，不是「该怎么补」——
> 要不要补、按什么优先级补，留给后面拍板。

---

## 起因

用户问：「自动跑一个任务，能保证成功吗？」分别对 DevLoop（`runUnit`）和 Company/OKR（Agent 招聘 + 任务委派）
两条链路查了代码。结论是同一个：**全系统没有任何一处能"保证自动跑到底"**，统一是
「重试到预算/时间窗耗尽 → 停下等人工」的模式，区别只在于兜底的**粒度**和**可见性**。

---

## 一、DevLoop `runUnit`（Coder→Tester 循环）

**文件**: `server/src/core/devloop/loop-controller.js`（`runUnit`，394-479 行）、
`server/services/devloop/unit-registry.js`（FSM）

- `retry_budget` 默认 5 次，每次失败把上一轮 `coder.log` 摘要 + Tester 失败原因打包成
  retry context 喂回 Coder，带着"上次为什么挂"重跑（reflection）。
- 5 次全挂 → `unitRegistry.block(...)`，状态机进 `blocked`（`unit-registry.js:36`）。
  **没有自动退出路径**，`blocked → pending` 只能靠人工干预。
- **当前默认走 mock 模式**（`opts.mock !== false` 默认 true），走
  `ClaudeCliProtocol({mock:true})` 回放 `fixtures/devloop-mock/*.json` 固定结果，
  不是真起 Claude CLI + 跑测试。所以"能不能保证成功"这个问题在默认配置下基本没有实际意义——
  mock 场景下结果是脚本编排好的，真实 CLI 下的成功率目前**没有实证数据**。要测真实场景
  得显式传 `mock: false`。
- 阶段现状：DevLoop 目前在 P2（单 Unit 循环），跨 Unit 的 `runProject`（P3）代码已经存在
  （同文件 556 行往下），但官方状态仍是"正朝 P3 推进"，还未收口。

---

## 二、Company/OKR Agent 任务委派

### 2.1 招聘装配的时间窗（`org-coder-has-no-shared-body` 记忆已同步更新）

**文件**: `server/services/company-service.js`（430、500-511 行）

- `hire()` 现在会现场校验一次角色定义是否就绪，用 `body_not_ready` 网关挡住别家公司在
  定义写完前重复招同一角色——比早前"静默退化成通用 Base Agent 且无报错"的状态好。
- 但 agent-creator 写 `agent.md`/`soul.md` 依旧是**异步触发 + 单会话锁**，校验和填充之间
  仍有时间窗，**没有完成回执/超时告警**。卡在这个窗口只能靠人工发现（比如逐个
  `head -3 data/companies/<公司>/agents/<本体>/agent.md` 看是不是还是 Base Agent 空壳）。

### 2.2 会话回收只有一层兜底

**文件**: `server/routes/agent-chat.js`（818-828 行，`CALL_KINDS` 表）

- `CALL_KINDS` 精确覆盖心跳/pipeline/日程/告警/日报五类，跑完即回收。
- 未标 `kind` 的调用退化成普通 `chat` 类型，靠 30 分钟空闲 TTL 兜底，**没有第二道防线**
  （例如全局会话数硬顶）。漏标的后台调用不报错，只在内存曲线上体现——
  与 `docs/done/claude-cli-session-leak.md` 记录的那次"2h43m 漏出 82 个进程/17.5GB"是
  同一类风险，这次风险面在 Company/OKR 委派路径上同样存在，不只是 agent-chat 原生场景。
  守卫 `agent-chat-session-reclaim.test.js` 已覆盖 `CALL_KINDS` 标注本身，但不覆盖
  "该标而没标"这类新增调用点的遗漏。

### 2.3 Graph 执行失败无自动恢复，与 DevLoop 同构

**文件**: `server/services/graph-engine.js`（`LOOP_HARD_CAP_EDGE` + fail 边路由）

- 有兜底边就转兜底节点，没有就直接进 `blocked` 停等人工，不会自愈。
- 这是委派链路的通用终态，不是 Company 独有问题——和 DevLoop 的
  `retry_budget` 耗尽 → `blocked` 是同一种设计选择（失败预算 + 人工兜底，
  不追求自动恢复），只是目前**分散在两套系统里各自实现，没有统一的"完成回执/超时告警"层**。

---

## 三、共性模式（值得记住，不代表已拍板要改）

三条链路（DevLoop unit、Company 招聘装配、Graph 执行）共享同一个设计现状：
**有失败预算 + 人工兜底，没有"卡住了主动通知人"这一层**。

失败之后系统会停在一个确定状态（`blocked` / `training` 卡住 / 会话挂着不回收），
但**不会主动喊人**——都是被动的，靠人去翻状态或者翻内存曲线才发现。
这是三处鸿沟共同的根因形状，不是三个独立问题。

---

## 参考

- DevLoop 阶段现状：[27-graph-agent-architecture.md](./27-graph-agent-architecture.md)
- 会话泄漏排查手册：[claude-cli-session-leak.md](../../done/claude-cli-session-leak.md)
- `body_not_ready` 网关所在的招聘流程背景：[28-followups.md](./28-followups.md)