Agent 架构该看动作和上下文复杂度，不该照搬 Claude Code
hugobowne · x · 2026-07-22
这篇长文的核心观点是：很多 agent 系统一上来就把架构做得太复杂，反而更容易失败。
- 作者认为，常见的“默认配方”——memory、compaction、sub-agent、编排、规划、hooks、guardrails、evals——并不适合作为所有 agent 的起点。
- 更好的方法，是先用两个维度给任务定位：
- 动作复杂度：要协调多少工具、决策、依赖和迭代。
- 上下文复杂度：跨多轮模型调用时，需要保留多少关键信息。
- 编程 agent 和 深度研究 agent 往往这两个维度都很高。
- 客服/销售 agent 通常上下文复杂度较低，难点更多在路由、工具暴露和何时交给人类处理。
- 作者还强调：动作复杂度 和 动作风险 不是一回事。一个只说一句话就会发退款、改预约、发邮件的 agent，虽然上下文不多，但仍需要严格权限和确定性检查。
- 最后的建议是：围绕你系统真正会遇到的失败模式来设计，而不是照搬某个成功案例的 harness。
「编程与Agent」频道最新
- 一份 Markdown 规则文件能修正 Claude Code 的坏习惯 — eyishazyer · 2026-07-22
- 用数据集删规则测 prompt，找出真正有用的指令 — _ScottCondron · 2026-07-22
- Anthropic 让 Claude 录屏学会可重复执行的任务 — TawohAwa · 2026-07-22
- Revid 用被监控的 GitHub 仓库自动生成更新视频 — tibo_maker · 2026-07-22
- LLM-as-a-Verifier 用连续分数提升 agent 评测 — solyarisoftware · 2026-07-22
- 开源 `CLAUDE.md` 把 Karpathy 编程建议变成 Claude Code 规则 — socialwithaayan · 2026-07-22