别追工具，基础公司会替你做整合
一个容易被忽略的事实是：前沿 AI 公司的员工本身就是 Agent 最重度的用户，他们有无限的 token 预算和最新的模型。如果某个问题真的存在，且社区里出现了好的解决方案，这些公司一定会把它整合进自己的产品。
回顾一下：skills、memory、subagents、规划功能——这些最初都是社区里的第三方方案，被验证有用后，逐一变成了 Claude Code 和 Codex 的内置功能。反过来，那些曾经"必不可少"的 stop-hooks？Codex 5.2 一更新，一夜之间就不需要了。
所以，你真正需要做的就是：偶尔更新你的 CLI 工具，看看新增了什么功能。不需要追着每个新包跑，不需要为"落后"焦虑。把精力花在理解 Agent 的工作原理上，比装一百个插件有用得多。
上下文就是一切
这是整篇文章最核心的观点：你给 Agent 的上下文质量，直接决定了它的输出质量。
当你装了太多插件、挂了太多内存系统、CLAUDE.md 写了两万多行，Agent 的上下文就会被大量无关信息淹没。你只是想让它写一个猜单词游戏，它却在翻 26 个会话之前的内存笔记、71 个会话之前的子进程管理记录。
原则很简单：给 Agent 完成当前任务所需的精确信息量，不多不少。你对这一点控制得越好，Agent 表现就越好。
研究与实现必须分开
上下文管理的第一个实操方法：把研究阶段和实现阶段拆开。
反面例子是这样的——你说"去构建一个认证系统"。Agent 必须先研究认证系统有哪些方案、各自的优缺点，上下文被塞满了各种可能性的技术细节。等到真正实现的时候，它更容易混淆或产生幻觉。
正面例子是这样的——你说"实现 JWT 认证，使用 bcrypt-12 密码哈希，刷新 token 轮换，7 天过期"。Agent 不需要研究任何替代方案，它确切知道你要什么，可以把全部上下文用在实现细节上。
当你确实不知道该选哪个方案时，做法也很简单：先开一个会话让 Agent 研究各种可能性并给出建议，你做完决策后，再开一个新的、干净的会话让另一个 Agent 去实现。两个阶段的上下文互不污染。
利用"讨好型人格"，而不是被它坑
Agent 有一个设计层面的特性：它非常想满足你的指令。这让它好用，但也会带来问题。
如果你说"在代码库中找一个 bug"，它一定会给你找到一个——哪怕它得编造一个出来。这不是 Agent 的问题，是你的提示方式在暗示"一定存在 bug"。
更好的做法是使用中性提示："搜索数据库模块，跟随每个组件的逻辑，报告所有发现。"这样 Agent 不会预设结论，有 bug 就报 bug，没有就如实描述代码行为。
更进阶的玩法是用对抗性 Agent 架构来利用这个特性：
- Bug 发现者 Agent：告诉它为发现的 bug 打分（低影响 +1，中等影响 +5，关键影响 +10）。它会非常积极地报告所有可能的 bug，包括一些误报。这是所有潜在 bug 的超集。
- 对抗性 Agent：告诉它每成功证伪一个 bug 可以得到该 bug 的分数，但如果证伪错误会被扣双倍分。它会积极地尝试推翻 bug 报告，但因为有惩罚机制，不会太鲁莽。这是实际 bug 的子集。
- 裁判 Agent：接收前两个 Agent 的输入，你（可以撒谎）告诉它你有标准答案，答对 +1 答错 -1。它会认真权衡双方的论据做出判断。
最终由裁判 Agent 确认的结果，再经过你的人工检查。实测下来，这个流程的准确率非常高。核心思路是：既然每个 Agent 都会努力"讨好"你的指令，那就设计出让它们互相制衡的结构。
让 Agent 知道任务何时结束
Agent 知道怎么开始一个任务，但不知道怎么结束。这会导致它实现了一半就声称"完成了"，留下一堆 stub 代码。
最有效的解决方案是测试驱动：明确告诉 Agent"除非这 X 个测试全部通过，否则任务没有完成；你不允许修改测试文件"。测试是确定性的，期望是明确的，Agent 无法糊弄。
另一个越来越好用的方式是截图验证：让 Agent 实现功能后截图，然后在截图上验证设计和行为是否符合预期。这对前端任务特别有用，能让 Agent 持续迭代直到视觉效果达标，而不是做完第一版就停了。
更系统的做法是为每个任务创建一个 {TASK}_CONTRACT.md，把完成标准写进去——需要通过的测试、需要验证的截图、需要满足的其他条件。然后在规则中告诉 Agent：在合同的所有条目都完成之前，不允许结束会话。
每个任务一个新会话，比长时间运行更好
很多人追求 24 小时不间断运行的 Agent，但这在实践中并不是最优解。原因还是上下文——长时间运行的会话会不可避免地积累大量无关上下文，导致后期任务的质量下降。
更好的架构是：
- 每个任务开一个独立的新会话
- 用一个编排层来管理任务的创建和分配
- 每当有新的事情需要做，就创建一个新任务并启动新会话来处理
这样每个 Agent 都在干净的上下文中工作，专注于自己的那一件事。
把 CLAUDE.md 当成目录，而不是百科全书
这是最重要的实操建议：把 CLAUDE.md 设计成一个逻辑化、嵌套的目录，用条件分支指向具体的上下文文件。
不要把所有规则都堆在 CLAUDE.md 里。它应该尽可能简洁，核心内容就是一系列 IF-ELSE：
- 如果你在写代码，阅读
coding-rules.md - 如果你在写测试，阅读
coding-test-rules.md - 如果测试失败了，阅读
coding-test-failing-rules.md
Agent 会忠实地遵循这些条件分支，按需加载上下文，而不是一开始就被灌入所有信息。
规则适合编码偏好——如果你看到 Agent 做了某件你不喜欢的事，就把它写成规则，告诉 Agent 下次做这件事之前先读这条规则。
Skills 适合编码配方——如果你有特定的方式想完成某件事，把步骤写成 Skill。你甚至可以先让 Agent 研究它打算怎么解决某个问题，把方案写成 Skill 草稿，你审核修改后，下次它遇到同类问题就会按照你认可的方式来做。
定期清理，避免规则膨胀
随着你不断添加规则和 Skills，它们迟早会开始相互矛盾，或者造成新的上下文膨胀——Agent 每次开始工作前要读 14 个 markdown 文件，和一开始上下文被插件淹没是同一个问题。
解决方法是定期让 Agent 帮你整合：把冲突的规则合并，把过时的 Skill 删除，把冗余的内容精简。整理完之后，Agent 的表现又会回到"魔法般"的水平。
说到底，让 Agent 高效工作的秘密并不复杂：保持简单的工具栈，精心管理上下文，用规则和 Skills 逐步塑造 Agent 的行为，理解并利用它的设计特性。没有完美的 Agent，你需要拥有最终结果的所有权——审查它的输出，验证它的判断。但在这个基础上，一个人能用 Agent 完成的事情，确实已经远超大多数人的想象。