让 AI 干活不难，难的是让它们一起把事情做完

以前写程序，我们关心的是函数怎么设计、模块怎么划分、数据如何流动。后来有了 AI Coding，我们开始把需求交给 Agent，自己退到后面做方案拆解、Code Review 和冲突仲裁。再往后走一步，当我开始尝试“让 Agent 管 Agent”时，我突然意识到一个变化：

写程序这件事，正在变得越来越像治理一个组织；而工程的对象，正在从“构建软件”扩大为“构建生产软件的组织”。

为什么今天 AI 越来越能干，很多开发者却越来越忙？
你开着十几个会话窗口，左边在重构，右边在查日志，中间在调样式。每个 Agent 都在干活，但没有任何一个窗口知道别的窗口刚刚改了什么。于是，模型还没有慢下来，人先成了最窄的带宽——你像一个没有接口的“人肉中间件”，在窗口之间复制、粘贴、补一句“继续”、再确认上一个结果有没有跑偏。

赫伯特·西蒙在《管理行为》里早就聊透了这件事：无论是人还是机器，注意力和上下文都是有限的。高层管理的核心，从来不是站在每个下属身后替他们做每一个决定，而是控制他们做决定时的前提——给什么目标、看什么环境事实、守什么验收契约。正如切斯特·巴纳德所说，组织不是一群人，而是“有意识地协调起来的活动或力量的系统”。

为了把“组织本身”当成工程对象来构建，也为了把自己从无休止的传话、催办和救火里解放出来，我们正在把这套在多项目高并发实践中反复打磨的体系整理成工具链，暂时称为 istack。工具链尚未对外发布，敬请期待。这篇先记录它的组织方式和运行机制。

它不做僵化的固定流水线，也不搞失控的自由群聊，而是用一套“组织拓扑 + 物理门禁 + 呈堂证供式验收 + 做梦与复盘进化”的机制，回答一个最朴素的问题：怎样让一件值得发生的事情，真正发生？

一、组织拓扑：告别“群聊过家家”与“中央集权”

管多智能体，最容易掉进两个极端陷阱：

第一个陷阱是“角色扮演式群聊”。很多人喜欢模仿传统职场，预设产品经理、架构师、开发、测试四个固定岗位，让几个 Agent 在群聊里边干边聊。但詹姆斯·汤普森在《行动中的组织》里算过这笔账：这种“互惠性依赖”的协调成本是最高的。实证数据同样表明，多智能体近四成的失败源于“相互理解错位”——冗长的聊天记录是最劣质的交接介质，下游还没干活，注意力就被上游的试错噪音污染了。

第二个陷阱是“中央集权的传声筒瓶颈”。我们早期曾用过“总管家 + 全局单一协调线程 + 作者线程”的架构。结果在一次 48 小时的高并发冲刺里，所有项目的 CI 状态、审查意见和合并请求全往一个节点挤，总管家两天跑了 508 次、收了近 560 条消息，协调线程换了三任接管者，合并排起长龙，人不得不连问五次“为什么还卡着”。

istack 的解法：动态特遣队、三层嵌套闭环与事件下沉。

我们借鉴了明茨伯格的“特别小组”与斯塔福德·比尔在《企业之心》中提出的“可行系统模型”，把组织重构为三层自包含的递归闭环：

1. 总管家彻底退出执行路径：它不再过问任何具体代码，只负责接纳人的意图、登记全局看板、维护跨项目组合与决策页，且只向各项目负责人派工。
2. 每项目设唯一的项目管家：负责单仓的任务拆解、共享文件锁、验收把关与串行合入主干。更重要的是，项目管家是写在看板上的逻辑职责而非固定窗口——执行节点可以按需创建或更换，满 100 轮就通过 handoff 换新线程，但看板上的状态、权限与业务积累绝不跟着节点一起消失。
3. 按文件边界切分与“一竿子捅到底”的作者线程：不设固定闲职，简单任务直接动手；需要并行时，先合入公共契约，再按互不重叠的文件写范围拆给作者线程。每个线程都在干净上下文里只读结构化的任务书，且必须自闭环跟到底——把 PR 推成 Ready 或回完评论绝不算结束，只有走到已合入交付、需人决定或明确阻塞这三种合法终态才准停机。
4. 事件下沉与“痛觉神经”：CI 红绿灯、审查评论直接送到负责这件事的作者或项目管家，绝不层层上报。但系统同时埋下了比尔所说的“痛觉神经”——普通修复在授权内自治推进；一旦触及资金账本、数据库迁移、权限底线，或是主干变红超 60 分钟且回滚失败，痛觉信号就会直接绕过中间层触发熔断，通过飞书决策卡推到人面前。

二、异构分工与物理护栏：设计条件，而不是靠提示词祈祷

不同模型有极强的“性格偏科”：擅长后端深度推理与挑刺的模型，往往容易写出过度设计的复杂结构，且极不擅长前端审美与自然文案。同时，再完美的文字规则，只要靠模型“自觉遵守”，在长上下文和高并发下就一定会走样。

istack 的解法：模型卡硬路由、“简洁性二审”与全链路 Hook 拦截。

这部分设计借鉴了瑞·达利欧在《原则》中介绍的“棒球卡”。它把一个人的长处、短处，以及支撑这些判断的记录放在一起，帮助人们判断工作该交给谁。我们把这个办法借到模型分工上：不先问哪个模型总体最强，而是看这次工作需要什么，它在哪些环节可靠，又容易在哪里出问题。

模型卡因此不是一份固定排名。卡上的擅长项和短板，要和具体任务、使用环境一起看；成本也会影响能否把某种能力放进日常流程。已经积累的观察和仍待验证的候选应该分开，随着实际交付继续修正。我们目前整理的七张卡片，呈现的就是这样一份选型记录。

下面是这套模型棒球卡的视觉呈现。卡片上的名称、参考价和能力描述来自个人与社区样本，不是官方评测或统一能力排名；标为“候选、待实测”的模型也不能当成已经验证的分工依据。

在分工上，我们把所有模型的角色映射收归单一配置表 model-cards.json：让逻辑最狠的模型负责后端实现与对抗性审查；让交互体感最好的模型负责前端与日常任务，并赋予它一项关键使命——对后端模型写出的代码进行“简洁性二审”，专砍画蛇添足的过度设计；把最贵的推理模型留给棘手架构决断；让文笔最自然的模型专职负责对外文档与长文成稿。

在执行边界上，我们在工具调用与回合收尾处埋下了四道物理守卫：

• 派工守卫：派工前强制校验模型卡参数与禁用黑名单，不合规直接阻断；
• 重命令与凭据守卫：拦截敏感文件读取，并把吃算力的构建、E2E 测试自动引流到远端算力机；
• 提问守卫：禁止在聊天框里用弹窗碎问打断人，可逆的“双向门”自己查历史偏好拍板，真正的“单向门”统一走飞书决策卡；
• 回合终态守卫：哪个智能体敢不带合法终态和真实证据就结束回合，或者敢用“详见上文”糊弄人，钩子当场把它拦回去重做。

三、交付即“呈堂证供”：PR 证据契约与铁板钉钉的验收门禁

正如明茨伯格所言，当你不去微操具体工作流程时，粘合整个组织的唯一方式就是把产出标准化。

在多智能体协作里，最危险的幻觉就是“Agent 说自己写完了”。大模型极擅长为了迎合指令而走捷径——写几个永远为真的空壳测试、拿 DOM 节点存在当作页面美观、或者改出新 Bug 后声称“已验证通过”。因此，在 istack 里，代码写完甚至本地测试跑通都算不上交付；每一个 PR 都是一份必须经受机器质检的“呈堂证供”。

1. 面向“两分钟读者”的 PR 正文与唯一证据评论

很多 Agent 写出的 PR 正文，要么是几百行改了哪些文件的流水账，要么塞满了内部 run-id、本机路径和哈希值。istack 用 pr_body.py 对 PR 文档施加了语法树级别的硬校验：

• 正文结论先行，证据全部折叠：折叠区外严格限高（如不超过 40 行），按“功能”或“修 Bug”固定章节顺序（功能必须依次为 一句话 → 你需要知道的 → 截图 → 验证；修 Bug 必须依次交代 一句话 → 问题 → 原因 → 改动 → 影响 → 截图 → 验证）。第一段必须在 80 字内用大白话讲清用户得到了什么，严禁出现配置键、代码反引号、本机路径或未带链接的工单号；所有命令输出与实现细节一律收进末尾的 <details> 折叠区。
• 单条证据评论原地更新：每个 PR 只准维护唯一一条带 <!-- pr-evidence --> 标记的作者证据评论，每轮修改后通过 API 原地更新，严禁在评论区刷屏式汇报进度。

2. 视觉与 UI 验收的“三节对账铁律”

对于前端与界面改动，DOM 断言和像素脚本绝不能替代真实的视觉审阅。凡是触及 UI 文件，必须提交桌面端与手机端两种宽度的关键路径录屏，以及关键状态截图。pr_media.py 会把录屏转成可内嵌预览的 GIF，同时保留完整原视频，再将录屏和截图推送到 review-assets/pr-N 专用孤儿分支，直接内嵌在证据评论中展示。
更严苛的是，pr_body.py 会强制检查证据评论中是否包含以下三个非空章节，缺一不可：

1. ### 用户原话：必须逐字引用本次要满足的用户原话或 UI 决定表条号，严禁靠转述模糊焦点；
2. ### 参照对比：必须在同一宽度下，将改后页面与参照页面或改前页面并排截图对比，所有对齐、间距与层级差异一目了然；
3. ### 新增可见元素：必须逐一列出本次新增的每个可见元素及其对应的用户要求；凡是用户没要求却擅自加上的副标题、解释文字或装饰元素，必须在送审前删干净。

3. 绑定精确版本的转 Ready 与合入大闸

在 istack 中，Agent 不准直接调 gh pr ready 或 gh pr merge，唯一受控入口是 pr_ready.py：

• 转 Ready 门禁：只有当 pr_body.py 校验正文与 UI 对账三节全部达标、针对当前提交版本的独立 AI 审查和简洁性二审已完成且无未决 P0/P1、受影响测试全部通过时，才允许从 Draft 转为 Ready；
• 四档风险分流与版本强绑定：pr_gate.py 按代码规模与敏感路径自动定级——超 2000 行的 split 退回拆分；审查超两轮未收敛的 simplify 停止点状打补丁，强制做整体简化重评；触及资金、迁移、权限或超 3000 行的 human 附上审计报告交人拍板；而符合条件的低风险 auto PR，则由项目管家在通过临时合并树检查（merge-checks.json）后，带着绑定当前精确 head SHA 的证据文件，通过 --match-head-commit 校验后自动串行合入。只要分支多推了一个 commit，旧的审查、旧的截图证据和旧的批准全部自动失效，必须重验。

四、人如何参与：方案、进展和决策

在目前的流程里，人主要通过行动方案、运行看板和决策卡参与工作。开工时，行动方案 Action Plan 用来对齐工作约定：这次要解决什么问题，准备怎么做，哪些判断仍是假设，交付物按什么标准验收，以及工作不能越过哪些边界。我更关心人在这里能否发现目标理解有误、方案依据不足，而不是让人逐条编写提示、安排每个智能体的下一步。方案也不能只是一份开工前的说明；执行中的调整需要保留与原目标的关系，才有依据判断工作是否偏离。

工作展开后，运行看板 Dashboard 负责呈现进展。人需要看清哪些已经交付，哪些还在处理中，哪里遇到阻塞，以及这些状态背后有什么证据。一次尝试结束，并不等于交付已经通过验收；看板上的结论应当能追溯到对应成果或检查记录。如果仍要靠人从多个聊天窗口搬运摘要、拼出当前进度，协调负担其实没有减少。按当前设计，看板承接的是对工作状态的持续查看，聊天可以保留，但不应成为了解进展的唯一入口。

需要人作出判断时，决策卡负责把问题说完整。这里的请求条件是目标发生冲突、选择具有高影响，或下一步超出已有授权；一般的执行细节不必都变成询问。卡中要有必要背景、可选路径、各自的利弊，以及智能体基于现有证据给出的建议，让人知道为什么此刻需要自己决定。人的明确选择随后进入工作依据，相关任务按这个决定继续，不能只埋在一条聊天回复里。回头检查时，也应能找到当时面对什么问题、作了什么选择，以及它如何影响后续工作。

这三个界面的职责分开，人的介入才有明确位置：方案承载开工约定，看板让执行过程可查，决策卡记录需要人承担的判断。这并不意味着流程已经彻底自治，也不意味着所有可逆操作都可以免于确认；是否需要请求人，仍取决于约定的权限和影响范围。我希望减少的是反复解释上下文和追问进度的劳动，而不是把责任含混地交给智能体。当前还需要继续改进这些信息的呈现，让方案、进展与决策之间的关联更容易查看。

五、做梦、复盘与纠偏：让组织拥有“自我新陈代谢”的能力

机制不可能一开始就完美。Agent 依然会犯错、会超时、会在同一个坑里反复摔倒。《系统之美》里有一条扎心的规律：去微调具体参数，往往是杠杆率最低的做法；真正的高杠杆动作，是改变信息流的结构，或者重写系统的运转规则。

如果每次出了错，只是往提示词里追加一句“以后请注意”，不出一个月，AGENTS.md 就会膨胀成几千行互相冲突的废话。为了解决这个问题，istack 设计了一套完整的“超时审计 + 工程复盘 + 记忆做梦 + 机制化纠偏”自进化闭环：

1. 超时审计与工程复盘

当任务卡运行超 12 小时未闭环，看门狗强制触发 overrun-review，核对真实状态并当场做出“继续、拆分、换手或终止”决断，留下 6 行极简尸检报告。在大特性结束后，retro 对研发环境做体检，检查导航指针、自动化检查、无效规则和工具消耗，把问题精准分流：真不知道的补指针，环境不通的修链路，写了规则却没遵守的严禁再加提示词，直接移交机制化纠偏。

2. 记忆“做梦”机制

定时或按需运行的 dream.py 会从上次“已审阅截止”游标出发，只读扫描跨平台会话与规模偏差账本。它严守“两次独立发生”铁律——单次失误只是数据，只有同一根因在不同会话中独立出现至少两次，才提炼为重复错误模式。同时通过 memory_dag.py 直接回查原始会话防止传话失真，旧规则打上 tombstone 归档，新规则用单向 supersedes 指针替换，保持常驻记忆永远精悍无环。

3. 机制化纠偏

一旦抓到重复两次以上的错误，交由 correct 转化为架构收口、类型约束、单测或拦截钩子；且必须先用历史真实翻车输入回放，证明新机制真能拦住旧错、修复后又能通过，才算闭环。

六、未来展望：算存分离与云端常驻

把组织本身当成工程对象来打磨，今天我们走出的只是第一步。顺着这条脉络往前看，基础设施也需要继续演进：

基础设施演进：从多机协同走向“算存分离”与“云端常驻”

目前，我们已经通过文件交接契约、跨设备双向同步以及重命令守卫，跑通了多设备协同的雏形。繁重的构建和 E2E 测试会自动交给远端算力机执行。进一步需要探索的，是算存分离与云端原生运行：

• 状态与记忆层：组织的意图、看板任务图、决策先例账本、长期记忆 DAG 以及交接契约，全部沉淀在独立于任何单台终端的持久化状态层中；
• 弹性执行层：各个项目管家与作者线程不再受限于本地笔记本的开合，而是变成云端按事件唤醒的无状态算力节点——GitHub 的一次推送、飞书卡片的一次点击、或是夜间的做梦定时器，都能在云端沙箱里瞬间拉起对应的执行单元，挂载所需的最小上下文切片，干完活写回证据后即刻释放。组织真正成为一个 7×24 小时在云端呼吸与运转的活系统。

把组织做成工程对象，并不是为了让人退出工作，而是让人不必一直靠传话和催办维持它运转。谁适合做什么，产物怎样检查，人的判断从哪里进入，出了问题又怎样修改机制，这些都需要在实际工作中一点点验证。工具链还在准备，先把这些关系理顺，再决定哪些部分值得交给它长期运行。

工具链：敬请期待

istack 还在整理和验证中，暂未开放下载或安装。本文先分享设计与实践，工具链的公开发布，敬请期待。