是这样的，我当时做这个多智能体协同平台，最直接的背景是：团队开始大规模用 AI 写代码以后，代码确实交付得更快了，但另一个问题也被放大了——过去一个人出错的影响是有限的，但是现在问题被进一步。
以前做 Code Review，Reviewer 至少还可以问开发同学：这个需求你是怎么理解的？为什么这么设计？哪些风险你验证过？但是 AI 参与之后，很多关键判断都散落在 Agent Session 里。最后 PR 里只剩一个 diff，至于中间怎么澄清需求、怎么选方案、调用过哪些工具、失败过几次、测试证据在哪里，Reviewer 很难看见。
所以这个项目一开始我想解决的不是“让某个 Agent 更聪明”，而是让团队成员在 AI 参与交付的时候，仍然能看懂过程、追溯证据、拦住风险，并且在必要的时候人可以接管。既然代码是我们最大最重的上下文，那么代码的理解就应该放在第一优先级。
如果用 Agent 设计里的双轴框架来看，我觉得这个项目的核心矛盾其实不是 Reasoning 不够强，而是几类东西开始失控了。
第一是感知失控。Reviewer 只能看到最终 diff，看不到需求背景、方案取舍、测试日志和风险证据。
第二是记忆失控。Agent 执行过程中产生了大量工具调用、命令输出、文件修改和失败重试，但这些东西没有变成后面能继续消费的工程记忆。
第三是协作失控。Planner、Dev Agent、Review Agent、人类审批者之间到底谁负责什么，如果不显式建模，最后责任边界会很模糊。
第四是治理失控。Agent 一旦能改文件、跑命令、触发测试，它就不只是聊天助手了，而是一个会改变工程状态的执行者。这个时候就必须有 Trace、Evidence、Gate、权限边界和人工介入口。
所以我后来对这个项目的定位就变了：它不是一个“多 Agent 聊天工具”，而是一个面向 AI 代码交付的可治理 Agent Harness。多 Agent 只是实现手段，真正的重点是让 AI 的交付过程变得可观察、可审查、可恢复、可接管。（3 分钟）
我把问题拆成了三个技术矛盾。
第一个矛盾是，AI Session 是对话式的，但软件交付是流程式的。需求澄清、方案设计、编码、测试、Review、合并，每一步的责任和验收标准都不一样。如果全部塞进一个长对话，后面就很难判断一个错误到底是需求理解错了，还是方案设计错了，还是实现阶段越界了。
第二个矛盾是，AI 产出是高频流式的，但团队协作需要稳定的过程状态。Agent 执行时会不断吐 token、工具调用、日志、文件变更和测试结果。如果只是把这些东西当消息流展示，关键信息很快就淹没了。团队真正需要的是：现在做到哪一步了？哪些证据已经有了？哪些风险还没关闭？下一步能不能继续？
第三个矛盾是，AI 任务链路很长，但工程系统必须允许人类中途介入和恢复。模型中断、命令超时、网络波动、工具失败都很常见。如果没有中间态沉淀，人接手时就不知道该从哪里恢复，也不知道应该重试、回退、换模型，还是直接人工修正。（5 分钟）
当时我也考虑过几种方案。
最简单的是做一个更强的多 Agent 会话，把规划、编码、Review 都放在同一个上下文里，让几个 Agent 自己聊。但这个方案的问题是，它只是把更多不确定性堆到一起。表面上看协作更强了，实际上上下文、责任边界、证据来源都更混乱。
第二种是做一条固定自动化流水线，让 Agent 按脚本完成开发和测试。这个对简单任务有效，但一遇到复杂需求就太僵硬。很多关键判断，比如需求是否理解对了、方案是否需要调整、风险是否接受，都不能完全自动化。
第三种是只做一个 Review Agent，在最后帮忙检查代码。但这个也不够，因为如果前面的需求理解和方案设计已经偏了，最后 Review 往往只能发现表层问题。它是在末端补救，不是在过程中治理。
所以我最后选择的是：把多智能体协作建模成一个人类可观察、可审查、可接管的软件交付流程。流程大概是：需求澄清 -> 计划设计 -> 受控开发 -> 证据审查 -> 门禁放行。
每个阶段都有独立的输入、输出、责任边界和退出标准。人类可以根据阶段证据决定继续、退回、暂停或者接管。这里我刻意不追求完全自治，而是让 Agent 在不同阶段承担有限职责。因为真实的软件交付不是“一个 Agent 说它做完了”，而是需求、实现、证据、审查和门禁之间能互相校验。（7 分钟）
具体来说，在需求澄清和计划设计阶段，Planner Agent 只能产出结构化执行计划、验收标准、风险点和关键文件范围，不能直接写代码。这样做是为了先把“要做什么、怎么验收、有哪些风险”说清楚。
到了受控开发阶段，Dev Agent 才能在计划边界内修改代码。它每一步都要记录工具调用、文件变更、命令输出和验证结果。如果它改了计划外的文件，或者没有补充测试证据，后面的 Gate 就可以拦住。
到了证据审查阶段，Review Guard 不再只听 Dev Agent 自己解释，而是拿最初的验收标准、执行计划、代码 diff、测试记录和 Trace 证据做比对。最后门禁阶段再决定这次变更能不能进入人工合并流程。
如果从执行拓扑上讲，这个平台不是单纯的多 Agent 并行，而是几个拓扑组合在一起。
首先是 Chain。研发过程按阶段推进，从需求到计划，再到开发、审查、放行。这样做是为了避免所有内容混在一个长上下文里。
然后是 Orchestrate。中心任务对象负责调度不同 Agent：什么时候交给 Planner，什么时候交给 Dev Agent，什么时候进入 Review Guard，什么时候需要人类审批。不是让 Agent 自己随便决定下一步。
再有是 Route。Gate 会根据风险、证据和验收标准决定继续、退回、暂停，还是转人工。
Hierarchy 也有，但我没有让它无限扩散。复杂任务可以委派给子 Agent，但子 Agent 拿到的上下文、权限和责任范围必须被限制，不能所有 Agent 都共享全部上下文和全部权限。
Loop 只用在失败恢复和 Review 打回里，而且必须有停止条件。比如最多重试几次、必须补齐哪些证据、什么情况下转人工，不能让 Agent 一直自我修补。
Parallel 不是默认设计，只在安全、性能、测试这类相对独立的审查场景里使用。否则并行 Agent 太多，反而会制造噪声。（10 分钟）
为了支撑这套流程，我主要做了四层设计。
第一层是流程编排层。系统把任务显式拆成阶段对象，而不是把所有内容塞进一段聊天记录。任务从计划设计进入开发时，系统会把计划、验收标准、约束上下文下发给 Dev Agent；从开发进入审查时，系统会强制要求 Dev Evidence，比如修改文件、测试命令、失败记录和风险说明。这样上下文不是散落在对话里，而是随着阶段流转不断结构化。
第二层是执行状态层。Agent 的执行不是一次性返回结果，而是持续产生事件。系统要把这些高频事件归并成稳定的阶段状态，比如哪些步骤已完成、哪些证据已生成、哪些风险还没关闭、当前是否允许进入下一阶段。这里的重点不是展示一个花哨的实时界面，而是把长任务过程变成可消费、可判断、可恢复的工程对象。
第三层是观测层。把一次长任务切成很多可恢复的步骤。AI 每完成一步，系统就把当时的输入、输出、依赖、耗时、Token、工具结果和文件变更沉淀成 Trace。Trace 不是普通日志，它的作用是让人能回答：这一步为什么这么做？失败了从哪里恢复？审查证据在哪里？
第四层是记忆层。这里我没有把 Agent Memory 理解成简单的聊天摘要，而是把它做成“执行过程的分层索引”。最底层是原始证据，比如工具返回、命令输出、文件 diff、测试日志；中间是 Trace 和 Session Digest，记录这次任务触达了哪些文件、用过哪些工具、失败过什么、验证信号是什么；协作层记录父子 Agent 的委派关系、启动上下文、完成摘要和验证结果；最上层只保留任务目标、当前阶段、关键证据入口和恢复路径。
这样后续 Agent 和人类不用重新读完整聊天历史，而是先读轻量摘要。如果不够，再沿着 digest、trace、原始证据逐层下钻。这个设计的价值不是让模型“背更多东西”，而是让系统把过程变成可引用、可恢复、可审查的工程记忆。（12 分钟）
这里还有一个很重要的判断：Agent 长任务最大的风险不是某一步错，而是错误会复合。
比如一个任务要经历需求理解、计划、编码、测试、Review、放行。哪怕每一步单看都还行，连续跑下来整体可信度也会下降。所以我在设计里做了几类防御。
对 Chain，我用阶段退出条件和结构化产物，减少错误一路级联到最后。
对 Route，我用 Gate 和人工审批，避免低质量结果被错误放行。
对 Orchestrate，我要求计划和任务拆解可审查，避免一开始就拆错方向。
对 Hierarchy，我用上下文隔离和权限边界，避免子 Agent 污染全局或者越权执行。
对 Loop，我设置最大轮次、验收标准和失败原因，避免 Agent 一直无意义返工。
对 Parallel，我要求审查结果能合并、去重、分级，否则多个 Agent 只是把噪声放大。
这套设计也带来了一些边界问题。比如复杂任务或者压测场景下，Trace 树会很大，不能一次性塞回上下文，也不能让 Reviewer 从头翻到底。所以观测层要支持按阶段、按风险、按文件变更下钻，重点是让人快速定位关键步骤，而不是展示所有细节。
再比如 Review Evidence 里可能包含大模型输出的 Markdown、HTML 片段和代码 diff，审查链路必须保留证据来源、验收标准和变更文件之间的对应关系。否则 Reviewer 看到的还是一堆结果，不知道该依据什么判断。
还有，不同 Agent 节点的输入输出不固定，所以流程节点需要用 Schema 描述参数、约束和产物。这样人类才能补充上下文、调整边界、中断流程，或者把任务退回上一个阶段。（14 分钟）
最终这个平台带来的改变，是把 AI 交付从“个人会不会写提示词”，变成“团队成员能不能真正理解自己的代码”。
开发者用 AI 时留下的不再只是一个对话记录，而是结构化计划、执行证据、分层记忆、Trace 和 Review 结论。Reviewer 看到的也不再只是 diff，而是 diff + plan + evidence + trace。人在任何时候介入，都不用从零猜上下文，可以沿着证据入口快速审查、接管、退回或放行。任务中断后，也可以从可解释的断点恢复，而不是全盘重来。
如果面试官问“怎么证明它有用”，我不会先硬说提升了多少百分比，而会先讲验证口径。
第一，看 Review 输入有没有从“只有 diff”变成“diff + plan + evidence + trace”。
第二，看任务中断后能不能定位到具体步骤，而不是让 Agent 整段重跑。
第三，看后续 Agent 能不能通过分层记忆恢复任务状态，而不是重新读完整聊天历史。
第四，看 Gate 有没有实际拦截过缺测试、越界改文件、未满足验收标准这类风险。
所以如果用一句话总结，我做的不是一个多 Agent 聊天工具，而是一个面向 AI 代码交付的治理型 Agent Harness。
它用 Chain 固化研发阶段，用 Orchestrate 调度不同 Agent，用 Route 做风险门禁，用 Hierarchy 管理委派边界，用分层 Memory 保留过程证据，用 Trace 和 Gate 让人类可以随时审查、接管、退回和放行。
这个项目真正解决的问题，不是某个 Agent 能不能把代码写出来，而是 AI 参与研发以后，需求、方案、代码、测试、证据和责任边界会不会断掉。我的目标就是让 AI 生成的代码带着上下文、过程、证据和人工决策入口进入团队协作，而不是只留下一个最终 diff。（15 分钟）
6. 核心防御与深挖靶场（面试官可能的追问）
在 15 分钟的面谈讲完上述框架后，面试官很可能会顺着下面几个点继续追问：
- ⚡ [执行状态层] 技术难点：高频事件如何沉淀为稳定阶段状态：如何用缓冲、批处理和状态机防止过程状态乱序 (Agent 运行时持续产生工具调用、日志和文件变更，系统如何把消息流归并成可审查的阶段状态？)
- ⚡ [观测层] 技术难点：海量追溯数据如何支持阶段恢复：如何让超大 Trace 树服务断点定位和恢复决策 (长任务 Trace 可能非常庞大，系统如何按阶段、风险和文件变更下钻，避免审查者淹没在细节里？)
- ⚡ [记忆层] 技术难点：长任务上下文恢复：如何把 Agent Memory 讲成分层证据索引 (长任务里工具日志、文件变更、子任务委派和验证结果不断膨胀，如何用 metadata、digest、trace 和原始证据逐层恢复上下文？)
- ⚡ [流程编排层] 技术难点：不同 Agent 节点如何表达输入输出边界：如何用 Schema 承载流程节点的参数、约束和产物 (不同 Agent 节点的输入、输出和人工补充项不固定，系统如何把它们描述成可校验的流程对象？)
- ⚡ [门禁层] 技术难点：证据链与风险拦截：如何根据验收标准、执行证据和代码 Diff 做门禁判断 (大模型输出和代码变更都不可完全信任，系统如何把 Evidence、Trace、验收标准和风险项串成可审查的放行依据？)