Agent 架构该看动作和上下文复杂度，不该照搬 Claude Code
hugobowne · x · 2026-07-22
这篇长文的核心观点是：很多 agent 系统一上来就把架构做得太复杂，反而更容易失败。
- 作者认为，常见的“默认配方”——memory、compaction、sub-agent、编排、规划、hooks、guardrails、evals——并不适合作为所有 agent 的起点。
- 更好的方法，是先用两个维度给任务定位：
- 动作复杂度：要协调多少工具、决策、依赖和迭代。
- 上下文复杂度：跨多轮模型调用时，需要保留多少关键信息。
- 编程 agent 和 深度研究 agent 往往这两个维度都很高。
- 客服/销售 agent 通常上下文复杂度较低，难点更多在路由、工具暴露和何时交给人类处理。
- 作者还强调：动作复杂度 和 动作风险 不是一回事。一个只说一句话就会发退款、改预约、发邮件的 agent，虽然上下文不多，但仍需要严格权限和确定性检查。
- 最后的建议是：围绕你系统真正会遇到的失败模式来设计，而不是照搬某个成功案例的 harness。
所属事件:生产级Agent实战反思：简单架构优于过度设计(4 条相关)→
「编程与Agent」频道最新
- MCP 链式调用无回滚：agent 工程的真实痛点 — agentrsdg · 2026-09-11
- DeepMind 等论文：设计文档当真相源，代码改为可抛弃产物 — Roger_M_Taylor · 2026-09-11
- 用 Agent 造小分类器：19 万文档标注成本仅 0.7 美元 — vanstriendaniel · 2026-09-11
- MathModelAgent 走红:自动完成数学建模并生成可提交论文 — jihe520 · 2026-09-11
- alphaXiv 开源 OpenResearch:用任意模型并行跑研究智能体 — alphaXiv · 2026-09-11
- 开源 AI 销售 OS DeskcommCRM 爆火:自带 Agent 与 WhatsApp 集成 — melgarafael · 2026-09-11