以我所主，为我所用

15分钟面谈：多智能体协同平台

16分钟阅读

是这样的，我当时做多智能体协同平台时，遇到的不是“怎么让 AI 多写一点代码”的问题，而是团队在引入 AI 编程后，代码交付的可信度反而变得更难判断了。

过去团队做 Code Review 时，真正困难的地方不是看 diff，而是理解这次改动为什么这么做。需求背景、方案取舍、风险判断，很多时候只存在于少数资深工程师脑子里。AI 进来以后，这个问题被放大了。代码生成速度变快了，但上下文被拆散在大量 Agent Session 里，最后提交 PR 的人可能也很难完整讲清楚“需求是怎么理解的、方案是怎么定的、哪些风险被验证过”。（2 分钟）

这个问题是从实际协作复盘里暴露出来的。我们发现 AI 帮忙写代码以后，PR 里的 diff 变多了，但 Reviewer 反而更难判断可信度。因为他看到的是最终结果，看不到中间的需求澄清、方案选择、工具调用、失败重试和测试证据。也就是说，AI 提升了产出速度，但如果没有过程证据，Review 成本会被转移到后面。

所以这个项目的业务问题，不是让单个 Agent 更聪明，而是让团队能在 AI 参与交付时随时看懂、介入和接管。代码要能被审阅，过程要能被追溯，风险要能被拦住，交接要能继续。否则 AI 写得越快，人类越容易失去对上下文、责任边界和风险判断的控制。

我把这个问题拆成了三个技术矛盾。

第一，AI Session 是对话式的，但软件交付是流程式的。需求澄清、方案设计、编码、测试、Review、合并，每一步的责任和验收标准都不同，如果全部塞进一个长对话里，后面就很难判断某个错误到底发生在哪个阶段。

第二，AI 产出是高频流式的，但团队协作需要稳定状态。Agent 每一步工具调用、日志、文件修改都会实时变化，前端如果只把它当聊天消息渲染，很容易出现 UI 撕裂、状态乱序和关键信息丢失。

第三，AI 的执行过程很长，但工程系统必须允许人类中途介入和恢复。网络波动、命令超时、模型中断都很常见，如果没有中间态沉淀，人既不知道该在哪一步接手，也很难判断是重试、回退、换模型，还是让任务回到上一个阶段。（4 分钟）

当时也考虑过几种方案。最简单的是做一个更强的 Chat UI，把多个 Agent 都放进一个会话里。但这样只是把更多不确定性堆到一个窗口里，流程边界还是不清楚。第二种是做一个自动化流水线，让 Agent 按固定脚本跑完开发和测试，这对简单任务有效，但遇到复杂需求时太僵硬，很多判断还是需要人介入。第三种是只做一个 Review Agent，专门在最后检查代码，但如果前面的需求理解和方案设计已经偏了，最后再 Review 往往只能发现表层问题。

所以我最后选择的方向，是把多智能体协作建模成一个人类可观察、可审查、可接管的软件交付流程。核心不是让某个 Agent 自主决定一切，而是用 Kanban 作为人机协作界面和编排状态机，把研发过程拆成 Todo -> Dev -> Review -> Gate 这些明确阶段。每一列不是 UI 上的状态标签，而是不同责任边界，也是人类判断是否放行、退回或介入的操作面。（6 分钟）

比如在 Todo 阶段，规划 Agent 只能产出结构化执行计划、验收标准、风险点和关键文件范围，不能直接写代码。到了 Dev 阶段，编码 Agent 只能在计划边界内局部修改，并且每一步要记录工具调用、文件变更和验证结果。到了 Review 阶段，Review Guard Agent 不再听 Dev Agent 自己解释，而是拿最初的验收标准和开发证据做比对。最后 Gate 阶段再决定这次变更是否允许进入人工合并流程。

这里面我刻意做了一个取舍：不要追求完全自治，而是让 Agent 在不同阶段承担有限职责。因为真实团队里，可信交付不是“一个人说他做完了”，而是需求、实现、证据、审查和门禁之间能互相校验。

为了支撑这套流程，我做了三层关键设计。

第一层是编排层。Kanban 的列迁移会触发不同 Agent 和不同工作流，但它首先是给人看的协作界面。任务从 Todo 进入 Dev 时，系统会把计划、验收标准和约束上下文下发给 Dev Agent；从 Dev 进入 Review 时，会强制要求 Dev Evidence，包括修改文件、测试命令、失败记录和风险说明。这让上下文不是散在聊天里，而是随着阶段流转不断结构化，方便人类随时判断“这张卡现在能不能继续走”。

第二层是交互层。Agent 的执行不是一次性返回结果，而是 SSE 高频推送，包括 token、工具调用、命令输出、文件变更和状态切换。前端不能每来一条就无脑 setState，所以我用了缓冲队列、批量合并和交互锁，把流式过程和稳定视图分开。这里的可视化不是为了炫技，而是让人能在长任务中看见 Agent 正在做什么、卡在哪里、改了哪些文件，以及是否需要暂停或接管。

第三层是观测层。我参考 React Fiber 的思路，把一次长任务切成很多可恢复的步骤。AI 每完成一步，系统就把当时的输入、输出、依赖、耗时、Token、工具结果和文件变更沉淀成 Trace。这样 Agent 中途失败时，Blocked Resolver 和人类 Reviewer 都能定位断点，恢复上一步上下文，再决定是重试、换模型、人工修正，还是退回上一个阶段。（10 分钟）

这套设计也带来了一些边界问题。比如复杂任务或压测场景下，Trace 树会变得很大，不能一次性塞给前端渲染，所以观测面板要做流式解析、树拍平和虚拟列表，但重点是让人快速定位关键步骤，而不是展示所有细节。再比如 Review Evidence 里可能包含大模型输出的 Markdown、HTML 片段和代码 diff，前端渲染时必须防 XSS，也要能让人顺着证据、验收标准和变更文件做判断。还有不同 Agent 节点的输入输出不固定，所以工作台里的表单不能写死，要根据 Schema 动态渲染，让人可以补充参数、调整上下文或中断流程。

最终这套平台带来的业务价值，是把 AI 交付从“个人会不会用提示词”，变成了“团队能不能治理人机协作过程”。开发者用 AI 时不再只留下一个对话记录，而是留下结构化计划、执行证据、Trace 和 Review 结论。人类在任何时候介入，不用从零猜上下文，可以沿着证据入口快速审查、接管、退回或放行。任务中断后也不是全盘重来，而是从可解释的断点恢复。

如果面试官问“怎么证明它真的有用”，我会按 目标、边界、证据、价值 的顺序，从证据链而不是单个效率数字回答。第一，看 Review 输入是否从“只有 diff”变成“diff + plan + evidence + trace”；第二，看任务中断后是否能定位到具体步骤，而不是让 Agent 整段重跑；第三，看 Gate 有没有实际拦截过缺测试、越界改文件、未满足验收标准这类风险。这里如果没有稳定统计周期，我不会硬说提升了多少百分比，而会把验证口径说清楚：我们衡量的是交付可审查性、失败可恢复性和风险可拦截性。

AI 协作能力在这个项目里也不是“会用工具”这么简单。我的重点是把提示词、执行计划、工具调用、代码变更和测试结果都变成结构化对象，让 AI 输出能够被人类审阅、被系统回放、被 Gate 拦截。这样 AI 不再是个人黑盒生产力，而是一个可以被人类监督、纠偏和接管的工程参与者。

从全流工程师角度看，这个项目真正解决的不是某个 Agent 能不能把代码写出来，而是 AI 参与研发以后，需求理解、方案设计、编码、测试、Review 和交付证据之间的知识流会不会断掉。

所以我没有把它做成一个单纯的聊天工作台，而是把 Task、Plan、Evidence、Trace、Gate 这些对象显式建模出来。产品和研发可以通过 Plan 对齐需求理解，开发过程通过 Trace 留下执行证据，测试和 Review 可以用 Evidence 校验验收标准，线上或交付后的问题也能沿着 Trace 回到具体阶段复盘。这样 AI 产出的代码不再只是一个最终 diff，而是带着上下文、过程、证据和人工决策入口进入团队协作。

这里体现的全流能力，是我能把一个“AI 编程效率工具”的问题，重新放回完整软件交付链路里看：前面要防需求理解偏差，中间要防执行过程失控，后面要让审查、恢复和复盘都有材料可消费。

如果用一句话总结，我做的不是一个多 Agent 聊天工具，而是把软件交付流程工程化、对象化，并且做成人类可以持续介入的人机协作系统。这个方案自然会引出几个深挖点，比如 SSE 高频推送下前端怎么防状态撕裂，超大 Trace 树怎么服务人工审查，动态 Schema 表单怎么支持人类补充上下文和接管流程，以及 Review Gate 里不可控的大模型输出和海量 diff 怎么安全、清晰地呈现给人判断。（15 分钟）

  1. 核心防御与深挖靶场 (面试官可能的追问) 在 15 分钟的面谈讲完上述框架后，面试官极大概率会顺着你的诱饵进行深挖。我已经为你准备好了以下 4 个独立的高频防御阵地（点击跳转复习）：

关系图谱

反向链接