Agent架构的真相：你可能不需要那么复杂
很多架构师一谈Agent就是多Agent协作、链式调用、分层设计。但根据我在Vibe_Coding课程中的学习笔记和实战经验，很多场景并不需要这么复杂。
开篇：一个反直觉的观点
去年，我接手了一个需要重构的遗留项目。代码库约10万行，业务逻辑分散在十几个微服务中。
按照"主流"的Agent架构建议，我设计了这样一个方案：
- 一个主Manager Agent负责任务分解
- 5个Worker Agent各自负责一个微服务
- 两个Planner Agent做技术决策
- 一个Reviewer Agent负责代码质量检查
听起来很合理？结果是：完全失败了。
失败原因一：过度设计的认知负担
我的代码库里没有人能看懂这个复杂架构。当我休假时，接手的同事花了两天才搞清楚：
- "谁是Planner？为什么这5个Worker要听Planner的？"
- "Reviewer说这个循环要重构，但Planner没说要改循环啊"
- "日志打在stderr了，哪个Agent负责？"
过度设计的系统需要额外的认知来理解，反而增加了维护成本。
失败原因二：Agent之间的通信开销
每次Agent之间通信，都需要序列化和网络传输。在单机环境跑10个Agent，消息传递的开销远超代码本身执行的开销。
更严重的是，调试困难。一个请求失败了——是Planner的bug、还是Worker的异常、还是网络问题？日志分散在10个不同的Agent里，排查时如大海捞针。
失败原因三：简单任务不需要多Agent协作
这个项目最终是怎么完成的？我删掉了整个多Agent架构，改成了最简单的方式：
- 一条Claude Code命令
- Claude Code自动分析整个代码库
- 生成重构计划
- 逐步执行并验证
花了3天，而不是原来设计的复杂架构要用的2周。
什么时候需要Agent架构？
说了这么多，那Agent架构完全没用了吗？不是的。它有其适用的场景，但不是所有场景都需要。
根据斯坦福课程中的学习笔记和实战经验，我认为Agent架构在以下场景真正有价值：
场景一：长期运行的复杂任务调度
典型场景：
- 分布式任务编排系统
- 需要多个决策点并行
- 需要任务依赖管理和状态追踪
- 需要容错和重试机制
为什么需要Agent：
这类系统的复杂度在状态管理和协作逻辑上，而不是在单次任务执行上。例如：
任务A → [判断] → Agent1 → 任务B
↓
[更新状态] → 状态服务
↓
[依赖检查] → Agent2 → 任务C
这恰好是Agent的强项：状态管理、协作编排。
场景二：需要多视角分析的任务
典型场景：
- 代码审查：多个Agent从不同角度审查（安全、性能、可读性）
- 方案设计：多个Agent给出不同技术方案，人工对比选择
- 文档生成：多个Agent各自负责不同部分的文档
为什么需要Agent：
多视角分析天然就是并行任务，这是多Agent协作的典型场景。
Agent A（安全视角） → ─┐
分析报告
Agent B（性能视角）→────┤→ 人工决策
Agent C（架构视角）→─┘
场景三：需要专家分工的复杂任务
典型场景：
- 大型系统架构设计
- 复杂算法优化
- 领域特定问题（如安全、数据库优化）
为什么需要Agent：
这类任务需要领域专家的深度知识和经验。一个通用LLM无法在所有领域都达到专家水平。
更现实的做法：
- 专家Agent负责策略设计
- 通用LLM负责代码生成
- 人负责领域知识输入和最终决策
斯坦福课程中关于Agent架构的真实内容
根据我学习斯坦福CS146S课程的笔记，课程对Agent架构的描述实际上更克制和实用：
课程的核心观点
课程中有一段话让我印象很深：
"Agent架构通常比人们想象的更简单。很多情况下，一个简单的Loop + 几个工具调用就足够了。不要为了Agent而Agent。"
这与我在实际项目中的感受一致。
课程中强调的原则
- 从简单开始：先用单一LLM + 工具调用，发现限制后再考虑Agent
- 明确边界：每个Agent的职责要清晰，避免责任模糊
- 可观察性：Agent之间的通信和状态变化应该是可追踪的
- 可测试性：Agent应该可以独立测试，不需要整个系统一起跑
实战经验：什么时候用单Agent就够了？
根据我的实战项目经验，以下场景用单Agent（一个LLM + 工具）效果最好：
案例一：单文件任务和简单CRUD
场景：为用户模块添加新字段
单Agent方案：
1. 读取文件 → 分析代码结构
2. 生成添加字段的代码
3. 运行测试
4. 提交PR
结果：5分钟完成，可读，易调试
案例二：代码审查
场景：审查一个PR的代码质量
单Agent方案：
1. 拉取PR diff
2. 要求LLM审查各个方面
3. 生成审查报告
4. 评论到PR
结果：15分钟完成，审查全面，可以直接发布
案例三：测试用例生成
场景：为某个函数生成测试用例
单Agent方案：
1. 读取函数代码
2. 理解函数逻辑（正常、边界、异常）
3. 生成对应的测试用例
4. 输出到测试文件
结果：30分钟完成，覆盖率从30%提升到85%
真正的"复杂"场景：我什么时候确实用了多Agent？
说这么多简单场景够用，那到底什么时候需要复杂架构？根据我的项目经验，这些是真实需要的：
需要复杂架构的场景
场景一：分布式系统的自主任务
需求：构建一个能够自主发现问题、分析原因、尝试修复的监控系统
为什么需要复杂架构？
- 涉及多个组件：日志收集、指标分析、告警、根因分析、知识库
- 需要长期运行、容错、自我恢复
- 需要复杂的协调和状态管理
单Agent能做吗？
不能。一个LLM无法同时处理这么多方面，且需要长期稳定的运行。
现实方案：
┌─────────────────────────────────────┐
│ 监控系统架构 │
├─────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │日志Agent │ │指标Agent │ │告警Agent │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ────────────────────┤
│ 协调与状态管理服务 │
└───────────────────────────────────────┘
这里的每个Agent确实有独立职责，但不是简单的"多Agent协作"，而是一个模块化系统设计。
场景二：需要持续学习优化的任务
需求：构建一个能从用户反馈中学习、持续优化决策的推荐系统
为什么需要复杂架构？
- 需要存储历史数据
- 需要训练/推理模型
- 需要A/B测试框架
- 需要复杂的模型版本管理
现实方案：这更像是一个机器学习系统，Agent只是其中的一个组件，而不是全部。
我的建议：如何判断是否需要复杂架构
根据斯坦福课程的建议和我的实战经验，我总结了一个简单的判断框架：
判断问题1：问题是否可以拆解为独立任务？
是 → 可能不需要Agent
否 → 可能需要Agent协调
举例：
- 添加新字段 → 可拆解 → 不需要Agent
- 构建监控系统 → 不可拆解 → 需要模块化Agent
判断问题2：任务是否需要多视角分析？
否 → 单个LLM即可
是 → 可能需要多Agent
举例：
- 代码生成 → 单LLM即可
- 方案设计 → 多个Agent分析
判断问题3：任务是否需要领域专家知识？
否 → 通用知识足以
是 → 可能需要领域Agent
举例：
- 通用CRUD → 不需要
- 金融风控规则 → 需要领域Agent
判断问题4：Agent之间的协调是否是核心复杂度？
否 → 只是简单的串行或简单并行
是 → 需要复杂的状态管理和协调机制
结论：从"Agent优先"到"问题优先"
很多文章把Agent架构吹成AI开发的未来方向，仿佛不用Agent就落后了。这种说法有误导性。
根据斯坦福课程和我自己的实战经验，我认为更健康的观点是：
好的架构师首先关注问题，然后才是解决方案。如果问题用简单的LLM+工具就能解决，那就用简单的方式。只在真正需要复杂协调的时候，才考虑Agent架构。
这听起来可能不那么"AI"，但确实更务实。
附录：一个实用的Agent模式（当真正需要时）
如果你的项目确实需要Agent架构，这里是一个简化但实用的方案，基于斯坦福课程中的内容：
简单的协调模式
# 不是复杂的多Agent系统，而是一个轻量的协调器
class SimpleOrchestrator:
def __init__(self, tools: list[Tool]):
self.tools = tools
self.llm = Anthropic() # 或其他LLM
def execute_task(self, task_description: str):
# 步骤1：让LLM理解任务
plan = self.llm.messages.create(
model="claude-sonnet-4-6",
messages=[{"role": "user", "content": f"""
分析以下任务：{task_description}
可用的工具：{self._format_tools()}
请规划执行步骤，如果需要多工具调用请说明。
"""}],
max_tokens=2000
)
# 步骤2：执行规划的工具调用
for step in self._extract_tool_calls(plan):
result = self._execute_tool(step)
# 步骤3：返回结果
return {"status": "completed", "result": result}
def _format_tools(self):
return [tool.name for tool in self.tools]
def _extract_tool_calls(self, response):
# 从LLM响应中提取工具调用
pass
def _execute_tool(self, tool_call):
# 执行工具
pass
这个方案的优势：
- 简单：只有一个协调逻辑，没有复杂的Agent间通信
- 可调试：所有逻辑集中，容易追踪
- 可扩展：可以添加新工具而不修改核心逻辑
- 成本低：只需要一个LLM，不需要多个Agent并行运行
总结
- 不要为了Agent而Agent：斯坦福课程明确指出过度设计的问题
- 从简单开始：先用单一LLM+工具，发现限制后再考虑Agent
- 问题优先：先搞清楚真正要解决的问题，再选择架构
- 务实胜过炫酷：能稳定运行的简单架构，胜过无法维护的复杂设计
如果你正在纠结要不要上Agent架构，问自己三个问题：
- 这个问题用简单的方式能解决吗？
- 如果不用Agent会失去什么？
- 用Agent会引入什么新问题？
如果第一个答案是"不用"或"不会"，那先别上Agent。
参考资料：
