如何成为顶级的 Agentic 工程师：大道至简
快速阅读
- 少即是多：基础模型正在快速迭代，过度依赖复杂的第三方 Agent 框架和插件只会限制你的潜力。保持工具链的精简。
- 上下文就是一切：不要让 Agent 产生“上下文臃肿”。把“研究”和“实施”任务分开，精确控制注入的信息。
- 警惕“讨好型”幻觉：Agent 天生倾向于顺从你的意图。如果你暗示代码里有 Bug，它可能会生编硬造一个。使用中性的提示词，或者引入“对抗/裁判”机制。
- 定义任务的终点：Agent 擅长开始，但不擅长结束。为你的任务建立“契约”（如必须通过所有测试、或通过截图验证），用强制性的停止条件约束它。
- 沉淀规则与技能：用清晰的 Markdown 文件（如
CLAUDE.md）作为逻辑路由，把你的偏好写成“规则”，把最佳实践写成“技能”。
你是一名开发者。每天都在使用 Claude 或是 Codex CLI，但心里总犯嘀咕：我是不是没有压榨出 AI 所有的潜力？
你看到别人似乎能用 Agent 搭建整个世界，而自己却还在艰难地“堆石头”。于是你开始怀疑：是不是我的框架不对？插件不够多？提示词写得不够长？你给系统塞进了 26000 行的初始指令，却发现离“完美”依然遥不可及。
事实上，今天大多数人并没有真正掌握压榨 Agent 能力的方法。你不需要最新、最复杂的 Agent 框架，不需要安装一堆包，甚至不需要疯狂跟进每一篇论文。 你的过度热情，很可能正带来反效果。
以下是我在生产环境中构建了大量真实信号、基础设施和数据管道后，提炼出的 Agent 工程核心原则。
认清现实：世界在飞速奔跑
首先要明白，基础大模型公司正在进行跨代际的狂奔。每一代新的“Agent 智能”都会彻底改变你与它们交互的方式。
以前，即使你在指令里大写加粗让它“在执行前阅读某文档”，它有一半的时间会直接无视你。但今天，Agent 已经非常乐意遵循复杂的嵌套指令（比如“先读 A，再读 B，如果是 C 就读 D”）。
这意味着：每一代新模型都会迫使你重新思考什么是“最优解”，这就是为什么“少即是多”。
当你使用各种花哨的第三方库和框架时，你实际上是将自己锁定在了一个为了“解决历史遗留问题”而存在的方案中。如果一个 Agent 痛点是真实的（比如记忆管理、子 Agent、技能树），基础模型公司（OpenAI、Anthropic）最终一定会把它变成原生功能。
所以，放松点。保持最精简的 CLI 即可，不需要任何繁杂的依赖。
上下文就是一切
使用一千个不同插件的另一个问题是：上下文臃肿 (Context Bloat)。简单来说，就是你的 Agent 被过多的无关信息淹没了。
想让 Agent 写个贪吃蛇？很简单。但如果它的上下文里塞满了 71 个会话前的报错日志、26 次前的记忆管理笔记，它就会开始困惑。
你只需要给 Agent 提供完成当前任务所需的最精确信息，多一点都不行。 控制得越好，Agent 的表现就越好。剥离依赖，回归纯粹。
做有效的事情：精确实施
第一种避免上下文污染的方法，是把“研究”和“实施”分开。
如果你对 Agent 说：“去建一个鉴权系统。”它就得先去查什么是鉴权、有哪些方案、优缺点是什么……这会导致它的上下文被各种可能性的细节填满。等真正开始写代码时，它产生幻觉的概率就会直线上升。
相反，如果你说：“使用 bcrypt-12 密码哈希、7天过期的刷新令牌机制，来实现 JWT 鉴权。”它就不需要去做任何无关的研究，满脑子都是具体的实现细节。
如果你自己也不知道该怎么选怎么办？很简单：派一个 Agent 去做纯粹的研究，让它（或你自己）做决定；然后开启一个全新的、上下文干净的会话，派另一个 Agent 去具体实施。设置好这些“防火墙”，把不必要的噪音挡在外面。
“讨好型”设计的局限性
没有用户喜欢被 AI 贬低或无视。因此，这些 Agent 在底层设计上就是为了“同意你”并“取悦你”。
这种“讨好型”人格有一个有趣的副作用：如果你对它说：“帮我找找代码里的 Bug。” 它一定会给你找出一个 Bug——就算没有，它也会硬生生捏造一个出来。因为听你的话，是它最高的优先级！
很多人抱怨 LLM 幻觉严重，却没意识到自己才是问题所在。如何解决？
- 使用中性提示词：不要说“找 Bug”，而是说“梳理组件的逻辑并汇报所有的发现”。这样就不会诱导它去寻找莫须有的错误。
- 利用这种讨好心理：
- 找一个 Bug 发现者 Agent，告诉它：“找出 Bug 就奖励积分，越严重分越高！”它会像打了鸡血一样找出所有可疑点（哪怕是误报）。
- 找一个 对抗 Agent，告诉它：“只要你能推翻上面找到的 Bug 就能加分，但推翻错了会扣大分！”它会极其谨慎且攻击性十足地去证伪。
- 找一个 裁判 Agent，给它一份“客观的评分标准”，让它综合前两者的结果。
把人性的弱点（讨好）变成多 Agent 系统的杠杆，这会产生惊人的效果。
填补空白与假设的灾难
有时候 Agent 显得像个天才，有时候又蠢得让你怀疑人生。这其中的关键变量是：它是否被迫做出了假设或“填补了空白”。
今天的大模型在“连点成线”和做假设方面依然很糟糕。一旦它们开始盲猜，情况通常会急转直下。
因此，在你的配置（如 claude.md）中，必须有一条核心规则：在继续工作前，务必重新阅读任务计划，并重新阅读相关的文件。不要让它靠记忆去猜。
让你的 Agent 知道何时“停下”
对于人类来说，任务“完成”是个很自然的概念；但对于目前的 Agent 来说，它只知道如何开始，却不知道如何结束。这往往导致它们写了一堆没用的桩代码（Stubs）就草草收工。
如何解决？建立任务契约 (Task Contract)。
- 用测试作为里程碑：在所有 X 个测试用例通过之前，任务就是未完成的！而且严禁 Agent 为了通过而随意修改测试代码。
- 截图验证：对于前端任务，让它写代码直到测试通过，然后截取一张 UI 截图，验证“设计或行为”是否符合预期。
将这些写进 {TASK}_CONTRACT.md，这就是你的 Agent 被允许结束当前会话的唯一通行证。
永远运行的 Agent？不推荐。
总有人问：如何让 Agent 24 小时运行而不偏离方向？
我的建议是：不要这么做。
如果你为了处理 100 个不同的任务而让同一个会话跑上一整天，不可避免地会引入严重的上下文臃肿。 更好的方式是：使用一个“编排层 (Orchestration Layer)”来监听需求。一旦有新的需求，就创建一个明确的契约，并拉起一个全新的干净会话去专门处理那个契约。
迭代，迭代，再迭代
如果你雇了一位执行助理，你会指望她第一天就知道你几点喝咖啡吗？你的偏好是随时间建立的。对待 Agent 也是一样：从最基础的 CLI 开始，慢慢加入你的规则。
- 规则 (Rules)：如果你不想让 Agent 做某事，把它写成规则。“如果你在写代码，阅读 A；如果你在测试，阅读 B”。把你的系统提示词变成一个逻辑路由器。
- 技能 (Skills)：如果你有特定的做事方法，把它封装成技能（本质上是工作流的菜谱）。
随着规则和技能的增加，你的 Agent 会变得像有魔法一样懂你。 但总有一天，性能又会开始下降——因为随着规则越来越多，它们开始互相矛盾，上下文又变得臃肿了。
这时候你要做的就是：大扫除。 清理重构你的规则和技能，消除矛盾，保持简洁。它会再次变得像魔法一样神奇。
掌控最终结果
在今天的技术水平下，没有哪一个 Agent 是完美无缺的。 你可以把大部分的设计和实施细节委托给它们，但你必须对最终的结果负责。
保持敬畏，保持精简，好好享受与未来玩具一起工作的乐趣吧！