最近读到一篇很长的文章：AI Agent 之我见。原文从 Claude Code、OpenAI Codex、Bub、Pi 这些 Coding Agent 的源码和实现差异出发，聊了上下文压缩、多 Agent、Shell 执行、安全模型和 prompt cache。

这篇不是转载，而是我作为学习者读完后的整理。以前看 Agent 更多是看“怎么用”，这篇文章提醒我：真正有价值的地方不只是功能说明，而是源码里那些边界处理、失败兜底和工程取舍。

读源码比读教程更能看到问题本身

教程通常会告诉我们一个 Agent Loop 长什么样：接收任务、规划、调用工具、观察结果、继续下一轮。但源码会暴露更真实的问题，比如：

  1. 上下文快满了怎么办？
  2. 自动压缩失败后要不要重试？
  3. 子 Agent 如何避免无限递归？
  4. 执行命令时如何处理超时和子进程？
  5. 自动模式下哪些命令必须拦住？

这些问题都不是“会不会写一个 demo”能覆盖的。一个 Agent 真正要长期跑起来，难点往往在异常路径里。

上下文压缩不是简单摘要

原文让我印象最深的是 compact。之前我对上下文压缩的理解比较粗糙：上下文太长了，就让模型总结一下历史。但几个项目的实现差异说明，压缩其实是 Agent 的核心能力之一。

Claude Code 的思路更像“交接文档”，要求摘要保留任务背景、关键代码、当前进度，甚至保留最近对话里的原文引用。这样做是为了减少语义漂移。因为 compact 之后，相当于一个模型把任务交给另一个模型继续做，交接信息越含糊，后续越容易跑偏。

Codex 的远程 compact 也很有意思：把压缩逻辑交给服务端，客户端只拿到加密后的 compact 结果。站在工程角度看，这样可以把模型、压缩策略和后续上下文恢复放在同一侧控制，但客户端就不容易观察到具体摘要内容。

我自己的理解是：compact 不只是省 token，它决定了 Agent 能不能做长任务。短任务靠模型能力，长任务靠记忆管理。

防止失败循环比成功路径更重要

原文提到 Claude Code 里有自动 compact 连续失败的 circuit breaker。上下文快满时触发 compact，但 compact 本身也可能因为 prompt 太长失败。如果没有限制，就可能进入“失败后继续压缩，压缩继续失败”的循环。

这对我挺有启发。平时写业务代码时也会有类似问题：重试逻辑本来是为了提高成功率，但如果没有上限、退避和状态判断，反而会把系统拖垮。

Agent 的失败循环更隐蔽，因为每一次失败都可能消耗一次模型调用。到了生产规模，小概率 bug 就会变成持续成本。

多 Agent 不是越多越好

多 Agent 听起来很强，但源码里的重点其实是隔离和控制：

  1. 子 Agent 需要有清晰的任务边界。
  2. 子 Agent 不能随意再创建子 Agent。
  3. 父子任务之间要有可追踪的上下文关系。
  4. 后台任务不能阻塞主任务，也不能悄悄失控。

这也解释了为什么成熟项目会跟踪 spawn 深度、限制工具集合，或者用独立进程隔离。多 Agent 的价值不是“多开几个模型”，而是把复杂任务拆成能并行、能收敛、能回收的子问题。

这点跟我平时使用 Codex 的感觉也比较一致：如果任务拆得不清楚，多个 Agent 只会放大混乱；如果任务边界明确，多 Agent 才能真正节省时间。

Shell 执行是 Agent 的现实入口

Coding Agent 最终还是要落到文件、命令、测试和构建上。原文里几个关于 shell 的细节很现实：

  1. 命令超时不能只杀父进程，还要处理子进程树。
  2. 交互式命令和非交互式命令要区分。
  3. vim、ssh、sudo 这类命令不能简单当普通命令跑。
  4. 自动模式下要对危险命令做额外限制。

这让我意识到，Agent 的工具层不是简单包一层 exec。工具执行环境本身就是安全边界，也是用户体验的一部分。

Prompt cache 影响架构设计

以前我以为 prompt cache 只是省钱优化，读完后发现它会反过来影响架构设计。

如果稳定内容和动态内容混在一起，每轮对话都会破坏缓存。成熟项目会把系统提示、工具定义、运行时状态、文件变化这些内容拆开，让稳定前缀尽量复用。

这其实跟后端缓存设计很像：不是“有缓存就行”，而是要知道哪些数据稳定、哪些数据频繁变化，以及缓存失效的代价。

对 Agent 来说，prompt cache 影响的不只是成本，还有延迟和长任务体验。

安全模型是产品选择

原文比较了几个项目的安全模型：有的依赖系统沙箱，有的靠权限分级和危险命令黑名单，有的用 hook 拦截，有的几乎没有限制。

我现在更能理解为什么 Coding Agent 需要 approval、sandbox、workspace 限制这些机制。模型再强，也不应该默认拥有无限权限。尤其是在真实开发环境里，仓库里可能有密钥、配置、数据库连接和部署权限。

一个比较稳妥的原则是：能放进沙箱的就放进沙箱，能只给 workspace 权限就不要给全盘权限，能让用户确认的危险操作就不要静默执行。

我自己的收获

读完这篇文章，我对 Agent 的理解从“模型 + 工具调用”往前走了一步。Agent 工程更像是在设计一个长期运行的工作系统：

  1. 模型负责推理，但 harness 负责让推理可持续。
  2. 工具调用提升能力，但权限控制决定风险边界。
  3. compact 延长上下文，但摘要质量决定任务能否接上。
  4. 多 Agent 提升并行度，但任务边界决定是否真的有效。
  5. prompt cache 降低成本，但信息布局决定缓存是否稳定。

如果以后继续读 Agent 源码，我会优先看这些部分：上下文管理、命令执行、权限系统、任务恢复、子 Agent 调度。因为这些地方最能体现一个项目是不是只停留在 demo，还是已经在面对真实用户和真实工程规模。

原文