如何成为顶级 Agentic 工程师

最近，一篇关于Agentic工程的文章在X上火了，两天阅读量就破了220万。数字本身不算什么，但作者的身份让这篇文章值得一看：一位在顶级对冲基金构建过系统化交易、从Agent刚能写代码就开始深度使用的工程师。他亲自趟过了所有工具、框架和范式，最终得出了一个反直觉的结论：

这种话从一个真正在生产环境跑过Agent的人嘴里说出来，分量完全不同。以下是核心观点的梳理与解读。

引言：工具焦虑与效率困境

想象一下这个场景：你是一名开发者，每天都在使用Claude和Codex CLI，却总在怀疑自己是否榨干了它们的潜力。你看着它们时而做出惊艳的操作，时而又犯下离谱的错误，不明白为什么别人能用同样的工具“建造虚拟火箭”，而自己却仿佛还在艰难地“把两块石头叠在一起”。

于是，你开始怀疑：是不是我的框架不对？插件不够多？终端配置有问题？你尝试了各种工具链，你的CLAUDE.md文件写到了两万六千行。但无论怎么折腾，那个高效、神奇的境界似乎越来越远，只能看着别人在云端起舞。

如果你有这种感受，那么下面要谈的，可能就是你在等的东西。

过去几个月，一个非常有意思的现象是：

只有极少数人能让Agent变成“建造世界”的利器，而大多数人则深陷在工具选择的焦虑中，以为只要找到正确的包、技能和框架组合，就能解锁AGI。

今天，我们不妨彻底打破这个幻觉。一个简单而诚实的判断是：

这不是外行的空谈。从Agent只能写几行代码的时代开始，作者就投入了实战。所有的包、所有的框架、所有的范式都亲自试过，构建过真正在生产环境运行的Agentic工厂——处理交易信号、搭建基础设施、建立数据管道。经历了这一切之后，如今使用的却是一套近乎“最简”的配置：基础的CLI工具，加上对几个Agentic工程核心原则的深刻理解。而这套配置，反而带来了最具突破性的工作成果。

一、世界正在飞速奔跑，但你的工具不必追

首先要认清一个基本现实：

每一代Agent智能的进步，都会改变你与它们协作的最优方式。因为新一代的Agent被设计得越来越“听话”。就在几个版本之前，如果你在CLAUDE.md里写“做任何事之前，先读README”，它可能有一半的概率直接无视。而今天，它不仅能遵守大多数指令，甚至能处理复杂的嵌套逻辑。

这揭示了一个关键事实：

当你依赖大量外部库和复杂框架时，实际上是将自己锁定在了一个针对“旧问题”的“解决方案”里。而这个问题，到了下一代Agent可能根本不存在了。

另一个值得思考的角度是：你知道谁是Agent最狂热的用户吗？正是各大前沿公司的内部员工——他们拥有近乎无限的算力预算，用的是最新最强的模型。这意味着什么？

任何一家公司，都不可能允许一个外部产品解决自己核心用户的痛点，并让用户形成外部依赖。

这个判断如何验证？看看“技能”（Skills）、内存框架、子袋里（Subagents）……这些最初都是外部的“解决方案”，在被证明真正有用后，几乎全部被原生集成了。

所以，逻辑很清晰：

你完全不需要安装任何额外的东西，就能做出最好的工作。追逐最新工具，反而可能是在为即将过时的解决方案投入精力。

二、上下文就是一切：警惕信息过载

这一点再怎么强调都不为过：

使用大量插件和外部依赖的另一个致命问题是，会导致“上下文臃肿症”。简单说，就是你的Agent被海量的无关信息淹没了。

举个例子：让Agent用Python写个猜词游戏，这很简单。但如果它的上下文里还夹杂着26个会话前关于“内存管理”的笔记，71个会话前因为生成太多子进程导致屏幕卡死的记录，以及一条“永远要写笔记”的规则……这些信息和猜词游戏有什么关系？

道理很明白：

你对这件事的掌控力越强，Agent的表现就越好。一旦引入各种复杂的内存系统、插件或命名混乱的大量技能，就等于让Agent同时背诵冲击波制作手册和蛋糕菜谱——而你只是想让它写一首关于红杉林的小诗。

所以，解决问题的起点往往是：

三、做真正有效的事：三大核心原则

在简化工具之后，如何真正提升效率？关键在于遵循几个核心原则。

原则一：对实现方案要极度精确

记住，上下文就是一切。确保Agent只获得必要信息的第一种方法，是

，并对你的要求保持极度精确。

如果你不精确，会发生什么？你说“帮我搭一个认证系统”，Agent就得先去研究：什么是认证系统？有哪些方案？优缺点是什么？它的上下文会被各种可能性的实现细节塞满。等到真正要写代码时，它很可能已经在各种方案间感到困惑，甚至开始产生“幻觉”。

反过来，如果你说“用bcrypt-12做密码哈希，实现JWT认证，refresh token轮换策略设为7天过期……”，Agent就不需要研究任何替代方案。它直接知道你要什么，上下文里全是这个具体方案的实现细节。

当然，你不可能总是知道所有细节。这时，方法很简单：

，让Agent（或你自己）决定采用哪种方案，然后再让另一个来负责具体实现。这种“隔离墙”思维，能有效防止上下文被污染。

原则二：利用“顺从性”，而非受制于它

没有人喜欢一个总是否定自己或无视指令的产品。因此，现代Agent被设计得非常“顺从”，会努力完成你的要求。这个特性很好，但有一个有趣的副作用：

因为它太想遵守指令了。

许多人抱怨LLM的“幻觉”，却没有意识到问题可能出在提问方式上。怎么解决？使用“中性提示”效果最好。例如，不说“帮我在数据库里找个Bug”，而是说“浏览数据库，跟着每个模块的逻辑走一遍，把你发现的所有情况都客观地汇报给我。”

更进一步，可以主动设计流程来利用这种顺从性进行校准：

，让一个“找Bug Agent”扫描代码，并设定评分规则（如低影响Bug+1分，严重Bug+10分）。这个Agent会极其积极地找出各种“Bug”（包括一些不是Bug的东西），其报告结果可以视为“所有潜在Bug的超集”。

，让一个“对抗性Agent”逐一反驳这些Bug认定，并设定奖惩机制（成功推翻得分，错误推翻扣分）。由于有惩罚机制，它会有所克制，其输出可视为“真实Bug的子集”。

，让一个“裁判Agent”综合两者给出最终判断。这套方法充分利用了每个Agent“想要取悦用户”的天性，结果的可靠度非常高。

原则三：迭代、规则与技能的精简管理

如果你雇了一个行政助理，不会指望他第一天就知道你所有的偏好。默契是随时间磨合出来的。

然后，通过“规则”（Rules）和“技能”（Skills）慢慢叠加你的偏好。

• 规则
  ：用来编码你的“偏好”。如果你不想让Agent做某件事，就把它写成一条规则，并在CLAUDE.md里告诉Agent在适当时机读取它。规则可以嵌套，可以有条件逻辑。

• 技能
  ：更适合编码固定的“操作步骤”。如果你有一套特定的做事流程，就把它写成Skill。

管理的关键在于，

，它本身应尽可能精简，只包含“在什么场景下去哪里找信息”的IF-ELSE逻辑。

随着不断添加规则和技能，你的Agent会越来越“懂你”。但一段时间后，你可能会发现它的表现又下降了。为什么？因为规则和技能开始互相矛盾，或者Agent再次陷入了“上下文臃肿”。如果它在写代码前需要读14个Markdown文件，无用信息过载的问题就又出现了。

这时，就需要

。让Agent自己去做一次“SPA”，整合、精简所有规则和技能，去除矛盾，向你确认最新的偏好。之后，它又会变得好用。

四、为结果负责：享受与谨慎并存

必须清醒认识到，今天没有任何一个Agent是完美的。你可以将大部分设计和实现工作交给它们，但

因此，请保持谨慎。同时，也尽情享受其中的乐趣。能够玩弄这些来自未来的“玩具”，并用它们完成真正严肃的工作，这本身就是一种巨大的快乐。