Agent 面试题：Multi-Agent 项目怎么进行测试与评估？

什么是 Multi-Agent ？就是一个由多个分工明确的 AI 角色编排而成的协作团队。每一个 Agent 各司其职，通过互相交流协作来实现复杂任务相比单 Agent 的优点降维解耦：单 Agent 在处理庞杂任务时，容易因为上下文过长而丢失焦点或产生幻觉。多智能体让每个 Agent 只专注特定领域，挂载专属的系统指令和工具，降低模型的认知负载交叉验证：Agent 之间能互相审查与辩论。比如“开发 Agent”写完逻辑，“测试 Agent”立刻跑测试用例挑错，这就是为什么一般流程后会加一个 correct_node非必要不升级一定要多 Agent 吗？一个需求，能用函数解决就优先函数，函数解...

很多设计题聊到最后，都会慢慢绕回“稳定性”这件事。一开始还没那么强烈的意识。觉得 Agent 设计题重点应该是架构怎么拆、工具怎么接、Memory 怎么存、RAG 怎么做，或者 Multi-Agent 怎么协作。结果面多了之后发现，这些东西聊着聊着，最后几乎都会被问到同一个方向：如果它出错了怎么办，如果它一直跑不回来怎么办，如果线上真的来很多请求怎么办。后来想想其实也挺正常。因为 Agent 这类系统和传统那种很固定的后端流程不太一样，它天然就更“不稳”。传统系统很多时候是你把规则写死，输入和输出路径都比较确定；但 Agent 不是，它中间有模型决策、有工具调用、有外部数据、有多轮上下文，链路一长，变量就会变得很多。只要中间任何一层开始飘，整个结果都可能跟着飘。所以面试官前面问你架构、问你 Tool Calling、问你 Memory，看起来像是在听方案，实际上很快就会往后问：这个方案怎么稳住。比如你说模型自己判断该调哪个工具，那下一句就可能是，如果它调错了呢；你说用了 Multi-Agent 去拆任务，那后面可能就会接，如果其中一个 Agent 输出错了，下游怎么处理；你说接了知识库做 RAG，那也很容易继续问，检索到了不相关内容怎么办，知识库更新不及时怎么办。Agent 设计题里最容易被忽略的一点就是，很多人会默认自己是在讲“理想链路”，但面试官其实更关心“非理想链路”。也就是说，你当然可以先讲正常情况下系统怎么跑，但如果你只会讲 happy path，后面大概率就会被一直追问。因为真正难的地方，本来就不是“它能不能工作一次”，而是“它能不能在复杂场景里别太失控”。而且这种稳定性，还不是只指服务别挂这么简单。它其实分很多层。最表层的是接口别报错、调用别超时，再往里一点是模型别乱调工具、别死循环、别把参数填错；再往后一点，是上下文别越跑越脏，Memory 别把旧信息带偏，多个 Agent 之间别互相污染；再工程一点，还会涉及监控、降级、重试、回滚、权限控制这些。现在再被问这种题，我会更有意识地去想两条线：一条是系统怎么工作，另一条是系统怎么出问题。很多时候后者反而更重要，因为 Agent 这类东西你只要真的做过一点，就会知道它最麻烦的从来不是第一轮跑通，而是后面怎么别失控。

核心定义ReAct 是能让大模型“边思考、边行动”的推理框架，让 LLM 像人类一样通过多轮交互解决复杂问题Thought-Action-Observation 运转逻辑ReAct 循环中有三大要点：Thought：模型分析当前的局面，大任务拆解成子任务，决定当前最需要做什么Action：根据前面的思考结果，生成具体的操作指令Observation：接收真实环境对操作的反馈结果这就有了一个闭环：想清楚再做，做完看反馈，基于新反馈接着想ReAct + Function calling 怎么运转？在 ReAct 需要与外部系统结合时，免不了调用工具，执行链路如下：评估与决策：模型接收用户请求，判断...

被裁了。 去年有多辉煌 现在就有多狼狈