夜雨聆风
如何成为顶级 Agent 工程师:少装插件,多做对的事
最近很多开发者都有同一种焦虑：
明明每天都在用 Claude、Codex，也配了不少插件、记忆层、自动化脚手架，但效果还是时好时坏。
你会怀疑是模型不够强、工具不够新、配置不够复杂。但这篇文章想给一个更扎实的答案：
Agent 工程的核心不是“更复杂”，而是“更清晰”。
1. 先接受一个现实：世界在高速迭代，重依赖会过时
模型能力在快速升级，今天必须外挂解决的问题，可能下个版本就被官方原生吸收。
所以工程上最稳妥的策略是：
-
1. 保持主链路轻量 -
2. 避免重度绑定外部 harness -
3. 用最少依赖获得最大可迁移性
很多人不是输在能力，而是输在“维护一套会过时的复杂系统”。
2. 上下文是第一生产力
Agent 最常见的失败不是“笨”，而是“被污染”。
当上下文里塞满历史噪声、无关规则、旧偏好，模型会开始跑偏，哪怕任务本身很简单。
一句话原则：
给 Agent 恰到好处的信息，不多也不少。
3. 把“调研”和“实现”拆开
很多低效都来自一句模糊指令：“去做个认证系统。”
这会让 Agent 同时做三件事：
-
1. 研究方案 -
2. 做技术选择 -
3. 执行实现
上下文瞬间膨胀，质量必然不稳。
更好的做法：
-
1. 先开调研任务，产出方案对比 -
2. 明确技术决策 -
3. 再开全新上下文做实现
这一步看似慢，实际是提速。
4. 理解“讨好性”，并反向利用它
Agent 天生倾向“满足你的请求”。如果你说“给我找 bug”，它会非常努力地找，甚至过度解读。
实操建议：
-
1. 用中性提示词，减少结果偏置 -
2. 用对抗流程做交叉验证（发现者 vs 反驳者 vs 裁判） -
3. 人类对高风险结论做最后验收
不要把“它想让你满意”误判成“它一定是对的”。
5. 任务结束条件必须写成“合约”
对人来说，“差不多做完”很自然。对 Agent 来说，这通常是灾难起点。
你要显式定义结束条件，例如：
-
1. 指定测试全部通过 -
2. 禁止改测试来“伪通过” -
3. UI/行为截图验证通过 -
4. 关键验收清单逐项勾选
如果没有合约，Agent 往往会在“看起来完成”时提前停工。
6. 长任务不如拆任务：一合同一会话
很多人追求 24 小时长跑 Agent。但超长会话几乎必然导致上下文漂移和任务串扰。
更优解是：
-
1. 一个 contract 对应一个 session -
2. 由编排层统一分发合同 -
3. 每个 session 只关注单一目标
这比“一个大会话干到底”更稳定、可追踪、可复盘。
7. 用 Rules 管偏好，用 Skills 管配方
这两个概念不要混：
-
1. Rules：约束不该做什么、何时读哪些规则 -
2. Skills：定义某类问题的标准做法（可复用配方）
另外，AGENTS.md / CLAUDE.md 最好只做一件事：\ 当目录用，告诉 Agent 在什么场景读什么。
它不该变成 2 万行百科全书。
8. 迭代比“完美配置”更重要
最有效的流程不是一次性搭神级系统，而是：
-
1. 先用最简配置跑起来 -
2. 出现问题就写规则/技能修正 -
3. 定期清理冲突规则和冗余技能 -
4. 持续收敛
Agent 的“好用感”来自长期调优，不来自一次堆料。
结语
顶级 Agent 工程师，拼的不是谁工具多，而是谁能长期稳定交付。
真正有效的方法其实很朴素：
-
1. 保持系统轻量 -
2. 严控上下文 -
3. 明确任务边界 -
4. 用合同定义完成 -
5. 持续迭代
你不需要追逐每个新玩具。你需要的是一套可重复、可迁移、可验证的工作流。
