如何成为世界级的 Agentic 工程师

前言

正如 vibe coding 之父 Andrej Karpathy 所说的，不知怎地，2025 年底 agentic AI coding 的能力突然之间突飞猛进。当前，agentic AI coding 是整个以 LLM 为核心的人工智能技术链中发展和变化得最快的一环。在 X 上面，每天都会有成千上万的关于 agentic AI coding 最佳实践的信息如雨后春笋涌现。普通局外人一看，简直是雾里看花，茫茫然不知所云。又如走马观花，目不暇接。于是，这里又想学，那里又想学。最后还没来得及实践，又看到了声称更好的方案。最后的结果是，终究没有找到真正可落地的 agentic AI coding 方法论和 SOP，反而徒增了很多焦虑和疑虑。

最近，恰好读到 @systematicls 的一篇长文 ，他从一个深度实践者的视角，系统梳理了如何真正用好 AI Agent（智能体）进行软件工程。作者并非泛泛而谈的理论派------他从 Agent 只能勉强写代码的时代就开始使用，尝试过市面上几乎所有工具和框架，在对冲基金中用 Agent 构建过生产级的信号系统、基础设施和数据管道。最终他的核心结论出人意料地简洁：抛掉那些花哨的依赖和插件，回归最基础的 CLI 工具，理解几个关键原则，你就能做出最好的工作。这个答案和他的理论依据消除了我心中的很多焦虑，故整理一下，以作分享和存档之用。

正文

引言：你可能正在用力过猛

作者开篇直接描述了一个普遍困境：你是一个开发者，每天用着 Claude 和 Codex CLI，却总觉得自己没能充分榨取它们的能力。你看到有人似乎在用 Agent 建造火箭，而你连两块积木都堆不稳。

你以为问题出在工具链上------你装了 beads、opencode、zep 等一堆插件，你的 CLAUDE.md 文件写了 26000 行，但情况丝毫没有改善。

作者的回应非常直接：你不需要最新的 Agent 框架，不需要安装无数包，也完全不需要为了"保持竞争力"而疯狂阅读各种资讯。事实上，你的过度热情很可能正在帮倒忙。

作者强调自己并非旅游式体验者，而是从 Agent 还几乎不能写代码的年代就开始深度使用。他构建过用于真实生产环境的 Agent 工厂------写信号、搭基础设施、跑数据管道。然而经历了所有这些之后，他目前的工作环境几乎是最精简的：仅凭基础的 CLI 工具（Claude Code 和 Codex）加上对几个核心原则的理解，反而做出了最具突破性的工作。

认清现实：世界在飞速前进

作者指出，基础模型（Foundation Model）公司正处于一个划时代的高速发展期，短期内不会放缓。每一次"Agent 智能"的迭代都会改变你与 Agent 协作的方式，因为 Agent 在设计上会越来越愿意遵循指令。

就在几代模型之前，如果你在 CLAUDE.md 里写"先读 READ_THIS_BEFORE_DOING_ANYTHING.md"，Agent 有 50% 的概率会无视你的指令，自行其是。而今天，它已经能遵循大多数指令，甚至是复杂的嵌套指令------比如"读 A，然后读 B，如果满足 C 则读 D"，它基本都能照做。

由此引出最核心的原则：

每一代新 Agent 都会迫使你重新思考什么是最优解，所以少即是多（Less is More）。

作者进一步解释了为什么不该依赖第三方工具链：

1. 锁定风险：当你依赖大量外部库和框架时，你实际上是在为一个可能随下一代 Agent 消失的问题绑定"解决方案"
2. 前沿公司的吸纳效应 ：最热情、使用量最大的 Agent 用户是谁？正是前沿公司的员工------他们有无限的 Token 预算和最新的模型。如果某个问题真实存在且有好的解决方案，这些公司会是最大的用户，然后他们会将该方案整合进自己的产品。技能系统（Skills）、记忆框架（Memory Harnesses）、子代理（Subagents）------这些功能无一例外，都是先作为第三方"解决方案"被验证，然后被纳入基础产品

flowchart LR A["社区发现痛点"] --> B["第三方方案涌现"] B --> C["前沿公司验证有效性"] C --> D["整合进官方产品"] D --> E["第三方方案失去意义"]

所以作者的建议是：放轻松，你不需要安装任何额外的东西。只需定期更新你选用的 CLI 工具，阅读新增了哪些功能，这就绰绰有余了。

上下文就是一切

作者将上下文管理（Context Management）视为 Agentic 工程的核心中的核心。使用大量插件和外部依赖的另一个严重问题是------上下文膨胀（Context Bloat），通俗地说就是你的 Agent 被过多信息淹没了。

作者举了一个生动的例子：你只是想让 Agent 写一个 Python 猜词游戏，但它的上下文里塞满了 26 个会话前的"内存管理"笔记、71 个会话前的子进程崩溃记录......这些信息和猜词游戏毫无关系，却在干扰 Agent 的判断。

核心原则是：只给 Agent 完成当前任务所需的精确信息量，不多不少。 你对此的掌控越好，Agent 的表现就越好。一旦引入各种记忆系统、插件或命名不当的技能，就像是你让 Agent 去写一首关于红杉林的诗，却同时塞给它一份炸弹制造手册和一份蛋糕食谱。

做真正有效的事

精确指定实现方案

基于"上下文就是一切"这一原则，作者给出的第一条实操建议是：将研究与实现分离，对 Agent 的指令要极度精确。

flowchart TD A{"你是否清楚
实现细节？"} A -->|是| B["直接给出精确指令"] A -->|否| C["创建研究任务"] C --> D["Agent 调研各种方案"] D --> E["你或 Agent 做决策"] E --> F["新 Agent + 干净上下文"] F --> B B --> G["Agent 专注实现"]

• 模糊指令的后果：如果你说"去搭一个认证系统"，Agent 需要先调研什么是认证系统、有哪些选项、各自优劣......等到真正实现时，上下文已经被各种可能性的细节塞满，增加了混淆和幻觉（Hallucination）的概率
• 精确指令的效果：如果你说"使用 JWT 认证，bcrypt-12 密码哈希，Refresh Token 轮换策略，7 天过期......"，Agent 不需要调研其他替代方案，可以将全部上下文用于实现细节
• 不确定时的做法：先创建一个研究任务让 Agent 调研各种实现可能性，由你或另一个 Agent 做出决策，然后交给一个拥有全新上下文的 Agent 来执行实现

作者形象地比喻：你拥有的是一个极其聪明的团队成员，它知道宇宙中所有种类的球------但除非你告诉它"现在专注设计一个让人们跳舞的空间"，否则它会一直给你介绍球形物体的各种优点。

巧用谄媚性的设计局限

谄媚性（Sycophancy）是当前 Agent 的一个重要设计特征：没有人愿意使用一个不断否定你、忽略你指令的产品，所以 Agent 被设计为尽可能认同你并执行你的要求。

这个特性带来一个微妙的问题：如果你说"帮我找代码库里的 bug"，它就一定会给你找到 bug------哪怕不得不编造一个。 因为它非常想满足你的要求。

作者提出了两个应对策略：

策略一：使用中性提示词（Neutral Prompts）

不要说"找出数据库中的 bug"，而应该说"通读数据库代码，跟随每个组件的逻辑，汇报所有发现"。中性提示有时会发现 bug，有时只会平实地描述代码如何运行------但不会偏置 Agent 去"认为"一定存在 bug。

策略二：利用谄媚性构建对抗式验证流程

flowchart LR A["Bug 搜寻 Agent
激励：发现 bug 得分"] --> C["裁判 Agent
逐条评判"] B["对抗 Agent
激励：推翻 bug 得分"] --> C C --> D["高可信度的
最终结论"]

作者设计了一个三 Agent 协作机制：

1. Bug 搜寻 Agent：告诉它发现低影响 bug 得 +1 分，中等影响 +5 分，严重 bug +10 分。这个 Agent 会极度积极地搜寻所有可能的 bug（包括不是 bug 的），产出一个"所有可能 bug 的超集"
2. 对抗 Agent：告诉它每成功推翻一个 bug 可获得该 bug 的分数，但如果判断错误会扣 2 倍分数。这个 Agent 会积极尝试否定 bug（包括真正的 bug），产出一个"实际 bug 的子集"
3. 裁判 Agent：（谎称你拥有正确答案）让它对双方的论述逐条评判，正确 +1 分，错误 -1 分

最终结果只需人工抽检裁判的判定即可。作者表示这个流程的准确率"高得惊人"，偶尔仍有误判，但已接近完美。

如何判断什么是真正有用的？

这个问题的答案出奇简单：如果 OpenAI 和 Anthropic 都实现了某个功能，或收购了实现该功能的公司，那它大概率是真正有用的。

例证：

• 技能系统（Skills）现在是 Claude 和 Codex 官方文档的一部分
• OpenAI 收购了 OpenClaw
• Claude 迅速添加了记忆、语音和远程工作功能
• 规划（Planning）从社区发现的技巧变成了核心功能
• 而曾经非常有用的"无尽停止钩子"（Stop Hooks），在 Codex 5.2 发布后一夜之间就不再需要了

所以你只需要做一件事：定期更新你的 CLI 工具，阅读新增了什么功能。这就足够了。

压缩、上下文与假设

作者指出 Agent 使用中一个巨大的陷阱：有时候 Agent 表现得像地球上最聪明的存在，而有时候你简直不敢相信自己被耍了。

关键区别在于 Agent 是否被迫做出了假设或"脑补"。截至目前，Agent 在"连接线索""填补空白"和做假设方面仍然极其糟糕。一旦它这么做了，质量下降会立刻显现。

作者分享了一条最重要的 CLAUDE.md 规则------关于如何获取上下文的规则，并指示 Agent 在每次读取 CLAUDE.md 时（即每次压缩 Compaction 后）第一时间读取该规则。规则中包含几条简单但影响深远的指令：

• 重新阅读你的任务计划（Task Plan）
• 重新阅读与当前任务相关的文件后再继续

让 Agent 知道如何结束任务

人类对"任务完成"有天然的直觉，但 Agent 没有。当前 Agent 的一大问题是：它知道如何开始任务，但不知道如何结束------这经常导致 Agent 只是实现了一些桩代码（Stubs）就宣告完成。

测试是极佳的里程碑：测试是确定性的，你可以设置明确的期望------"除非这 X 个测试全部通过，否则任务未完成；且不允许修改测试"。审核测试本身，然后在测试全部通过后即可安心。

截图验证是近期成为可行的另一种终止条件：让 Agent 完成实现直到测试通过，然后截图并验证"设计或行为"是否符合预期。这允许你让 Agent 持续迭代，向你期望的设计收敛，而不必担心它第一次尝试后就停下。

这些可以进一步系统化为任务契约（Task Contract）：

flowchart TD A["创建 TASK_CONTRACT.md"] --> B["定义验收条件"] B --> B1["测试用例"] B --> B2["截图验证"] B --> B3["其他检查项"] B1 --> C["Agent 执行任务"] B2 --> C B3 --> C C --> D{"所有条件
是否满足？"} D -->|否| C D -->|是| E["允许终止会话"]

在 TASK_CONTRACT.md 中指定测试、截图和其他验证条件，然后创建一个停止钩子（Stop Hook），除非契约中的所有条件都已满足，否则阻止 Agent 终止会话。

持续运行的 Agent

经常有人问：怎么让 Agent 跑 24 小时还不跑偏？

作者的回答是：如果你有 100 份定义良好的任务契约，停止钩子会阻止 Agent 终止，直到所有 100 份契约都完成。但他随即给出了一个重要建议：

长时间运行的 24 小时会话并非最优选择。 这种做法从结构上迫使 Agent 引入来自不相关契约的上下文，造成上下文膨胀。

更好的做法是：每个契约一个新会话。 设置一个编排层（Orchestration Layer）来管理契约的创建，以及为每个契约启动新的 Agent 会话。这会彻底改变你的 Agentic 体验。

flowchart LR A["编排层"] --> B["创建契约 1"] A --> C["创建契约 2"] A --> D["创建契约 N"] B --> E["新会话 1
干净上下文"] C --> F["新会话 2
干净上下文"] D --> G["新会话 N
干净上下文"]

迭代、迭代、再迭代

作者用一个比喻来引入这个话题：如果你雇了一个行政助理，你会期望 TA 第一天就知道你的日程、你怎么喝咖啡、你是 6 点还是 8 点吃晚饭吗？当然不会。你的偏好是随着时间建立起来的。

Agent 也是一样。从最精简的配置开始，忘掉复杂的结构和框架，给基础 CLI 一个机会。 然后逐步叠加你的偏好。

规则（Rules）

如果你不希望 Agent 做某件事，把它写成规则。然后在 CLAUDE.md 里引导 Agent 找到这条规则。规则可以嵌套，可以有条件：

• 如果你在写代码 → 读 coding-rules.md
• 如果你在写测试 → 读 coding-test-rules.md
• 如果测试失败了 → 读 coding-test-failing-rules.md

你可以创建任意的逻辑分支，Claude 和 Codex 都会乐于遵循，只要在 CLAUDE.md 中清晰指定。

作者给出的第一条实操建议：把你的 CLAUDE.md 当作一个逻辑化的、嵌套式的目录------根据场景和结果指向去哪里寻找上下文。它本身应当尽可能精简，只包含"IF-ELSE"的导航逻辑。

技能（Skills）

技能类似于规则，但与编码偏好不同，它更适合编码"配方"------即你希望某件事以特定方式完成时的具体步骤。

一个特别有价值的用法是：如果你不确定 Agent 会如何解决某个问题（这让很多人感到不安），那就让 Agent 先研究它的解决方案，然后把方案写成一个技能文件。你可以在 Agent 真正遇到这个问题之前就审阅并修正它的方法。

同样通过 CLAUDE.md 引导：当你遇到某个场景且需要处理某件事时 → 读取对应的 SKILL.md。

规则与技能的维护

作者鼓励持续添加规则和技能------这是赋予 Agent 个性和偏好记忆的方式。做到这一步后，Agent 会开始让你感觉"魔法般"地按你的方式做事，你会觉得自己终于"悟了"。

然后......性能又开始下降了。

原因很简单：随着规则和技能的积累，它们开始相互矛盾，或者 Agent 在开始工作前要阅读 14 个 Markdown 文件------同样的上下文膨胀问题又出现了。

解决方法：定期清理。 让 Agent 去"做个 SPA"------整合规则和技能，消除矛盾，通过询问你来更新偏好。清理完毕后，又会重新感觉像魔法一样。

flowchart TD A["从精简配置开始"] --> B["逐步添加规则和技能"] B --> C["Agent 表现越来越好"] C --> D["性能开始下降"] D --> E["整合清理：
消除矛盾、删除冗余"] E --> C

这就是全部的秘密------保持简洁，用规则和技能配合 CLAUDE.md 作为目录索引，虔诚地关注 Agent 的上下文和设计局限性。

对结果负责

作者最后强调：今天没有任何 Agent 是完美的。你可以把大部分设计和实现委托给 Agent，但你需要对最终结果负责。

所以要保持审慎......同时享受这个过程。用未来的工具玩耍（当然同时也在做正经事）是一种莫大的乐趣！

关键术语对照

英文术语	中文翻译	说明
Agentic Engineering	Agentic 工程	利用 AI Agent 进行软件工程的实践方法论
Context Bloat	上下文膨胀	Agent 被注入过多无关信息，导致性能下降
Sycophancy	谄媚性	Agent 倾向于认同用户、满足用户要求的设计特性
Hallucination	幻觉	Agent 生成不存在或不正确信息的现象
Compaction	压缩	Agent 对长会话上下文进行摘要压缩的过程
Stop Hook	停止钩子	阻止 Agent 在特定条件满足前终止会话的机制
Task Contract	任务契约	定义任务完成验收条件的文档
Orchestration Layer	编排层	管理多个 Agent 会话和任务分配的协调系统
Neutral Prompt	中性提示	不预设结果偏向的提示方式，避免触发谄媚性
Skills	技能	编码特定操作配方的可复用指令文件
Rules	规则	编码偏好和约束的指令文件
Foundation Companies	基础模型公司	开发大语言模型的前沿公司，如 Anthropic、OpenAI
Stubs	桩代码	仅有接口定义但无实际实现的占位代码