有效使用 Code Agents

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the text, I’ll provide a Simplified‑Chinese translation while keeping the source link, formatting, markdown, and any code blocks unchanged.

概览

每当大型语言模型（LLMs）获得一次“升级”，它们就像魔法一样——第一印象总是非常强烈。
这正是我使用代码代理时的感受：模型突然对我的系统具备了超强的上下文感知能力，并且能够反复迭代问题，直至产生可运行的解决方案。

最疯狂的部分是？我甚至不需要理解解决方案，因为代理已经帮我实现了它。

但正如常情一样，玩转这项新能力很快就会暴露出硬性限制。超出玩具项目后，代理开始大幅偷工减料，而当你尝试编辑一个大型代码库时，它们往往彻底失败。

最新的模型（GPT‑5‑Codex、Sonnet 4.5）已经进入了堪比新工程师的能力水平。然而，它们需要极其细致的指引，不能像一位热情的新毕业生那样随意放手。模型足够聪明，几乎可以完成任何任务，但离不开大量的团队协作。

下面，我将详细说明我在使用当前这批前沿 LLM 和工具时，所采用的获取良好结果的策略。

1. 上下文的价值胜过黄金

即使拥有大规模的 token 窗口，每个 token 都是可能破坏结果的毒药。问题主要来自三个方面：

成本

• 按照当前 Anthropic 的计费标准，单个提示的费用可能超过 30 美元。

任务负载

• 模型会考虑其系统提示、它发现的每个 # TODO、所有指令等。
• 这些因素叠加会导致模型困惑。

检索

• 每个模型对 token 限制的处理方式不同；实际上，它们并没有在“记忆”中真正容纳数十万 token。
• 检索可能是当前 LLM 发展中最 重要 的方向，但仍 远未解决。

2. 代理之代理：一种“疯狂黑客”技巧

让你的主代理 调用其他代理 可以带来三大好处：

1. 更高质量的答案 – 新的代理在干净的上下文中处理子任务。
2. 更小的主代理上下文 – 保持主代理的 token 窗口精简。
3. 成本节约 – 提示更短 = 调用更便宜。

代码配对的典型工作流

在工作中使用代理进行代码配对时，常会出现两类任务：

• 运行构建系统
• 通过 MCP 阅读专有文档

这两者只需要少量信息，但工具会倾泻出巨大的 token 负载：

• 平均文档页约 10 k token
• 一个小的 make 构建可能产生 数千个 token

解决方案： 创建一个全新的代理并告诉它，例如：

“Run make build. I edited xxx.hpp. Let me know if there are any errors.”

随后代理会返回简洁的二进制反馈，如 “Your change worked” 或详细的错误信息。

3. 模型特定优势

• Claude Code v2.0 在此模式下表现尤为出色。
• 我过去会自行管理周期并频繁启动新模型，但现在我可以保持同一个聊天会话。

“这更多是感觉而非严格规则，但在实现新功能并通过测试后，我倾向于进行压缩——几乎与我提交代码时的里程碑相同。”

4. 在大型专有仓库中工作

• 你必须在任务分配时极其明确，但又不能向模型提供过多信息。
• 将所有文档和文件夹一次性塞入上下文会lobotomizes模型。

实用技巧

1. 明确告诉代理要查看的具体位置以及实现时应走的路径。
2. 如果你不知道答案，使用几个不同的代理收集相关信息，并帮助你为执行代理制定精准的提示。

5. 避免 “有毒” 的系统级提示

不佳示例

“使用 uv 执行所有 Python 命令。”

模型在每一步都记住了这条规则，即使我们已经不在 Python 仓库中，它仍然遵循该规则。

建议

• 避免使用范围过大的系统级提示。
• 在 每个仓库 中细化提示或 AGENTS.md。

真实案例

我在一个旧仓库中使用一个已废弃的工具，该工具在每次构建时都会打印升级警告。模型误以为警告是根本原因，便开始安装最新更新，导致环境被破坏。最终我通过包装函数来隐藏该警告，问题得以解决。

6. 分层代理协作

将其视为更高层次的子代理：

• 一个管理代理与我一起关注宏观视角，并帮助为工作代理制定提示。
• 管理代理了解高层目标；工作代理负责低层执行。

典型工作流程

1. 打开两个终端：
   • 管理代理 – 持续运行，了解整体目标。
   • 工作代理 – 当达到上下文限制或走错路径时经常被重置。
2. 与管理代理协作，决定向工作代理提供哪个提示。
3. 当工作代理卡住时，管理代理帮助识别缺失的上下文或更高层次的方案。

“这是一个高度迭代的过程。”

我认为当前这一批模型已经足够好，能够完全自动化：管理代理可以以编程方式拆分并分配任务。我尚未在最新模型上进行测试——Sonnet 4不足，但Opus 4.1已相当接近。

7. 自我验证至关重要

代理与聊天机器人的一个关键区别是 代理必须能够检查自己的工作。

• 为代理提供明确的 构建和测试 代码的路径。
• 在实现之前编写 测试（可以是自己编写，也可以是另一个代理）。
  • 测试充当紧密的反馈回路。
  • 它们还可作为出色的文档，使代码比一段英文描述更为简洁。

8. TL;DR – 产生影响的组合

通过将上下文视为珍贵资源、在专门的代理之间拆分工作以及强制自我验证，你可以从当今最前沿的 LLM 中获得可靠且成本效益高的结果。

回答质量

Anthropic 最近发布了一篇事后分析，承认其基础设施中的漏洞导致模型性能下降。因此，如果某一天某功能正常而下一天失效，可能并不是你的错。

如果有人发布了新更新，最好亲自尝试，以了解哪种模式、工具或任务的组合真正表现出色。

保持上下文紧凑，子代理更紧凑。你能做到的最好方式是让上下文尽可能小，并且如果当前路径不佳，不要害怕彻底重启。

我一直在想，随着下一代模型的出现，这些东西可能会变得无关紧要，但每次新模型发布，我发现自己需要跟踪的东西越来越多。我确实已经被代理取代了一些工作，但我们离让它们大规模构建酷炫东西还有很长的路要走。