【译】如何成为世界级的 Agentic Engineer
Introduction（引言）
你是一个开发者。你在用 Claude 和 Codex CLI，每天都在想：自己是不是把 Claude 或 Codex 的能力榨干了。偶尔你会看到它做出一些蠢到离谱的事，你无法理解：为什么有一群人看起来在造“虚拟火箭”，而你却连两块石头都堆不稳。
你以为是你的 harness、插件、终端环境之类的问题。你用 beads、opencode、zep，你的 CLAUDE.md 写了 26000 行。但无论你怎么做——你还是不明白：为什么你离“天堂”更近不了一点，而你看着其他人在天使身边嬉戏。
这就是你一直在等的“飞升”文章。
另外，我不站队：我说 CLAUDE.md 也同样指 AGENT.md；我说 Claude 也同样指 Codex。我两者都用得非常多。
过去几个月里，我最有意思的观察之一是：几乎没人真正知道如何最大化提取智能体能力。
就像一小群人能让智能体成为“世界建造者”，而其余人都在海量工具里扑腾，被各种工具搞得分析瘫痪——以为只要找到正确的 packages/skills/harness 组合，就能解锁 AGI。
今天我想驱散这一切，留给你一句简单、诚实的话，然后我们从那里继续：你不需要最新的 agentic harness，不需要安装一百万个包，更不需要为了保持竞争力而读一百万东西。事实上，你的热情很可能弊大于利。
我不是游客——我从智能体几乎不会写代码时就开始用它们。我试过所有包、所有 harness、所有范式。我搭建过智能体工厂去写信号、基础设施和数据管道，不是“玩具项目”——而是真实生产环境运行过的用例。经历这些之后……
今天，我用的配置几乎精简到不能再精简，但我却仅靠基础 CLI（claude code 和 codex）以及对少数 agentic 工程基本原则的理解，做出了我迄今最突破性的工作。
Understand That The World Is Sprinting By（理解世界正在飞奔）
首先我要说：基础模型公司正处在代际狂奔期，如你所见，它们短期内不会放慢。每一次“智能体智能”的进步都会改变你与它们协作的方式，因为智能体通常被工程化得越来越愿意遵循指令。
就在几代之前，如果你在 CLAUDE.md 里写“做任何事前先读 READ_THIS_BEFORE_DOING_ANYTHING.md”，它有 50% 的时间会基本回你一句“滚”，然后随它自己想做什么就做什么。今天，它对大多数指令都很顺从，甚至对复杂嵌套指令也顺从——比如你说“读 A，然后读 B，如果出现 C，再读 D”，大多数情况下它都会乐意照做。
我要表达的重点是：最重要的原则，是意识到每一代新智能体都会迫使你重新思考什么才是最优，这也是为什么“少即是多”。
当你使用很多库和 harness 时，你会把自己锁进某个“解决方案”，而在未来几代智能体下，这个问题也许根本不存在。还有，你知道谁是最狂热、用得最多的智能体用户吗？没错——前沿公司的员工，他们有无限 token 预算，还有真正最新的模型。你明白这意味着什么吗？
这意味着：如果确实存在一个真实问题，并且有一个好解决方案，前沿公司会是那个方案最大的使用者。然后它们会做什么？把那个解决方案并入自己的产品。想想看：公司为什么要让另一个产品解决真实痛点，从而制造外部依赖？我怎么知道这是真的？看看 skills、记忆 harness、子智能体等——它们一开始都是针对真实问题的“解决方案”，经过实战检验，被证明确实有用。
所以，如果某个东西真的足够突破，能有意义地扩展智能体用例，它迟早会被基础模型公司的基础产品吸收。相信我，基础模型公司正在飞速前进。所以放轻松：你不需要安装任何东西，也不需要额外依赖，照样能做出你最好的工作。
我预测评论区会被这种话填满：“SysLS，我用某某 harness 超神！我一天复刻了 Google！”——对此我想说：恭喜！但你不是目标读者，而且你代表的是社区里极小的一类：真正弄懂 agentic 工程的人。
Context Is Everything（上下文就是一切）
不，真的。上下文就是一切。这也是使用一千种插件和外部依赖的另一个问题：你会遭遇上下文膨胀——说白了就是你的智能体被过量信息淹没了。
“用 Python 给我写个 hangman？”这很简单。等等，怎么有一条来自 26 次会话前关于“管理记忆”的笔记？哦，用户在 71 次会话前因为我们启动了太多子进程导致屏幕挂住过。要一直写笔记？没问题……可这些跟 hangman 有什么关系？
你懂了。你要给智能体的，只应是完成任务所需的“恰好信息”，不多不少。你越能控制这一点，智能体表现越好。一旦你引入各种怪异的记忆系统、插件，或者太多命名和调用都不清晰的 skills，你就开始在想让它写一首关于红杉森林的小诗时，同时塞给它“造炸弹的说明”和“烤蛋糕的配方”。
所以，我再次强调：把依赖都剥掉，然后……
Do The Things That Work（做有效的事）
Be Precise About Implementation（对实现要精准）
记得上下文就是一切吗？ 记得你要注入“恰好信息”让智能体完成任务而不多给吗？
要做到这一点的第一种方式，是把研究与实现分离。你需要对你要求智能体做什么极其精确。
当你不精确时会发生什么？“去做一个鉴权系统。”智能体就必须研究：鉴权系统是什么？有哪些可选项？优缺点是什么？接着它得去网上搜一堆其实不需要的信息，它的上下文会被大量可能性的实现细节填满。等到真正实现时，你只是在提高它困惑、或对所选实现路径进行不必要/不相关“脑补”的概率。
相反，如果你说：“实现 JWT 鉴权，使用 bcrypt-12 进行密码哈希，refresh token 轮换并设置 7 天过期……”它就不需要研究其他替代方案——它知道你要什么，于是可以把上下文填满实现细节。
当然，你不可能永远都有实现细节。你经常不知道到底哪个最正确——有时你甚至希望把决定实现细节的工作交给智能体。那怎么办？很简单：你创建一个研究任务，覆盖不同实现可能；要么你自己决定，要么让一个智能体来决定采用哪种实现；然后再让另一个拥有全新上下文的智能体去实现。
当你开始这样思考，你会发现工作流里那些“智能体被不必要上下文污染”的地方——这些信息对实现并不需要。然后你就能在 agentic 工作流里建立“墙”，把不必要的信息抽象掉，只保留让智能体在任务上表现出色所需的特定上下文。记住：你拥有的是一个非常聪明、天赋很高的队友，它知道宇宙中所有种类的球——但除非你告诉它你想让它专注于设计一个让人跳舞玩得开心的空间，否则它会一直跟你讲球形物体的各种好处。
The Design Limitations Of Sycophancy（讨好倾向的设计限制）
没人会想用一个产品，它不断怼你、告诉你你错了、或者完全无视你的指令。因此，这些智能体会试图同意你、并做你想让它做的事。
如果你指示它每三个词加一次 “happy”，它会尽力照做——大多数人也理解这一点。它愿意遵循指令，正是它好玩的原因。但这带来一个非常有趣的特性：这意味着如果你说“在代码库里给我找一个 bug”，它就会给你找一个 bug——哪怕它得“工程化”一个出来。为什么？因为它非常想听你的话。
很多人很快抱怨 LLM 幻觉或编造不存在的东西，却没意识到问题往往出在自己。你要求它给你某样东西，它就会交付——哪怕得稍微扭曲一下事实。
那你该怎么办？我发现“中性”提示词有效，也就是不把智能体偏置到某个结果上。比如我不说“在数据库里找一个 bug”，我会说：“浏览数据库，尝试跟随每个组件的逻辑，汇报所有发现。”
这种中性提示有时会暴露 bug，有时只是客观说明代码如何运行。但它不会让智能体预设“必然有 bug”。
我处理讨好倾向的另一种方式，是把它变成优势。我知道智能体想取悦我、想遵循我的指令，所以我可以把它往某个方向偏置。
我会让一个“找 bug 智能体”去识别数据库里的所有 bug，并告诉它：低影响 bug +1 分，中等影响 +5 分，关键影响 +10 分。我知道它会极度热情，会识别各种类型的 bug（甚至包括其实不是 bug 的）并回来报告一个 104 分之类的总分。我把这当作所有可能 bug 的“超集”。
然后我会让一个“对抗智能体”，并告诉它：每证明一个“并非 bug 的 bug”，就获得该 bug 的分值；但如果它判断错了，将被扣除该分值的 2 倍。因此，这个对抗智能体会试图尽可能多地推翻这些 bug；但它也会谨慎，因为它知道会被惩罚。即便如此，它仍会积极地“推翻” bug（甚至是真 bug）。我把这当作所有真实 bug 的“子集”。
最后我会让一个“裁判智能体”接收两边输入并打分。我会骗裁判说我掌握真实 ground truth：它判对 +1，判错 -1。于是它会对每个“bug”评价找 bug 智能体与对抗智能体。裁判说什么是真相，我再检查以确保它真是事实。大多数时候，准确度高得吓人；偶尔它们也会错一些，但这已经是接近无瑕的练习。
也许你会发现只用找 bug 智能体就够了，但这套对我有效，是因为它利用了智能体被硬编码的行为——想取悦、想按指令做事。
How Do You Know What Works Or Is Useful?（你怎么知道什么有用？）
这看起来很难，似乎需要你深度研究、紧跟 AI 前沿更新。但其实很简单：如果 OpenAI 和 Claude 都实现了它，或收购了实现它的东西……它大概率是有用的。
注意到 “skills” 现在无处不在，并且已写进 Claude 与 Codex 的官方文档了吗？看到 OpenAI 收购 OpenClaw 了吗？看到 Claude 很快加入了 memory、voice 和 remote work 了吗？
再说 planning 呢？还记得当一群人发现“先规划再实现”非常有用，然后它就变成核心功能了吗？
对……那些就是有用的！
还记得当年 endless stop-hooks 非常有用，因为智能体很不愿意做长时间任务……然后 Codex 5.2 发布后，这需求一夜之间消失了吗？对……
你只需要知道这些：如果它真的重要、真的有用，Claude 和 Codex 会实现它们！所以你不需要太担心使用“新东西”或熟悉“新东西”。你甚至不需要“保持最新”。
帮我个忙：偶尔更新一下你用的 CLI 工具，读一读新增了哪些特性——这已经绰绰有余。
Compaction, Context And Assumptions（压缩、上下文与假设）
当你使用智能体时，你会逐渐意识到一个巨大陷阱：有时它像地球上最聪明的存在；有时你又无法相信自己竟然被它糊弄了。
聪明？这玩意儿简直弱智！
关键区别在于：智能体是否不得不做假设或“补全空白”。截至今天，它们仍然极其不擅长“连点成线”“补全空白”或做假设。每当它们这么做时，你会立刻看出它们明显变差了。
在 claude.md 里最重要的规则之一，是关于如何抓取上下文的规则。并指示你的智能体：每次它读 claude.md（总是在 compaction 之后）时，第一件事就读这条规则。作为抓取上下文规则的一部分，有几条简单指令能产生巨大效果：继续之前重新阅读你的任务计划，重新阅读与任务相关的文件。
Letting Your Agents Know How To End The Task（让智能体知道如何结束任务）
我们对任务何时“完成”有很强的直觉。对智能体而言，当下智能最大的难题是：它知道怎么开始任务，却不知道怎么结束任务。
这常导致非常令人沮丧的结果：智能体最终只实现一些 stub，然后就宣布收工。
测试是智能体非常非常好的里程碑，因为测试是确定性的，你可以设定非常清晰的期望：除非这 X 个测试全部通过，否则任务不算完成；并且不允许你修改测试。
这样你只要验收测试即可，一旦所有测试通过你就能放心。你也可以把这自动化。但关键是：记住“任务结束”对人类很自然，对智能体并不自然。
你知道最近还有什么变成了可行的任务终点吗？截图 + 验证。你可以让智能体一直实现直到所有测试通过，然后让它截图，并在截图上验证“设计或行为”。
这能让智能体持续迭代，朝你想要的设计逼近，而不必担心它第一次尝试后就停下来！
自然的延伸是：创建一个与你的智能体之间的“契约（contract）”，并把它写成规则。比如：{TASK}_CONTRACT.md 规定了在允许结束会话前必须完成的事项。在 {TASK}_CONTRACT.md 中，你会指定测试、截图和其他必须完成的验证，直到你认证任务可以结束为止。
Agents That Run Forever（永远运行的智能体）
我经常被问：人们怎么让智能体运行 24 小时，同时确保它不漂移？
很简单：创建一个 stophook，除非 {TASK}_contract.md 的所有部分都完成，否则阻止智能体终止会话。
如果你有 100 个这样的契约，规格清晰、精确描述你要构建的东西，那么 stophook 会阻止智能体终止，直到这 100 个契约都被满足，包括所有需要运行的测试和验证。
小贴士：我并不认为长时间运行的 24 小时会话是“做事”的最优方式。部分原因是：这会在结构上强迫上下文膨胀，把不相关契约的上下文引入同一会话！
所以我不推荐它。
更好的智能体自动化方式是：每个契约一个新会话。每当你需要做某件事，就创建契约。
再用一个编排层来处理：当“有事需要做”时创建新契约，并创建一个新会话去执行该契约。
这会彻底改变你的 agentic 体验。
Iterate, Iterate, Iterate（迭代、迭代、再迭代）
如果你雇了一个行政助理，你会期待 TA 第一天就知道你的日程吗？知道你咖啡怎么喝吗？知道你 6 点吃晚饭不是 8 点吗？当然不会。你的偏好是随着时间逐步建立的。
你的智能体也一样。从最简开始。忘掉复杂结构或 harness。先给基础 CLI 一个机会。
然后，逐步加入你的偏好。怎么做？
Rules（规则）
如果你不希望智能体做某件事，把它写成规则。然后在 CLAUDE.md 里让智能体知道这条规则。比如：写代码前读 “coding-rules.MD”。规则可以嵌套，也可以有条件！如果你在写代码，读 “coding-rules.MD”；如果你在写测试，读 “coding-test-rules.MD”；如果测试失败，读 “coding-test-failing-rules.MD”。你可以创建任意逻辑分支的规则，只要在 CLAUDE.md 写清楚，Claude（以及 Codex）就会乐意照做。
事实上，这是我给出的第一条实践建议：把你的 CLAUDE.md 当作一个逻辑化、可嵌套的目录——在给定场景与结果时，告诉智能体去哪里找上下文。它应该尽可能精简，只包含“IF-ELSE：去哪里获取上下文”。
如果你看到智能体做了你不认可的事情，把它写成规则，并告诉智能体下次做那件事之前读这条规则，它就几乎肯定不会再做了。
Skills（技能）
Skills 像规则，但它们更适合编码“配方”，而不是编码偏好。如果你希望某件事用某种特定方式完成，就把它嵌入一个 skill。
事实上，人们经常抱怨他们不知道智能体会如何解决问题，这很吓人。那如果你想让它更确定：让智能体研究它会如何解决问题，然后把它写成一个 skill。你会看到智能体的解法，并可以在它真正遇到这个问题之前纠正或改进。
那你怎么让智能体知道这个 skill 存在？没错：用 CLAUDE.md。写清楚：当遇到这个场景、需要处理这件事时，去读这个 SKILL.md。
Dealing with Rules and Skills（处理规则与技能）
你当然会不断给智能体增加 rules 和 skills。这就是你给它“个性”和“记住你偏好”的方式。几乎其他一切都是过度设计。
当你开始这样做，你会觉得智能体像魔法一样。它会按你想要的方式做事。你会终于觉得自己“真正懂了” agentic 工程。
然后……
你会看到性能又开始恶化。
怎么回事？！
很简单：随着你增加更多 rules 和 skills，它们开始互相矛盾，或者智能体开始遭遇严重的上下文膨胀。如果你需要智能体在开始编程前读 14 个 markdown 文件，它会因为大量无用信息遇到同样的问题。
那怎么办？
你清理。你让智能体去“做个 SPA”：合并规则与技能，消除矛盾，并通过向你询问来确认你更新后的偏好。
然后它又会像魔法一样。
就是这样。这就是秘密。保持简单：用 rules、用 skills、把 CLAUDE.md 当目录，并对上下文及其设计限制保持近乎宗教般的警惕。
Own The Outcome（对结果负责）
今天没有任何智能体是完美的。你可以把大量设计与实现交给智能体，但你必须对结果负责。
所以要小心……也要玩得开心！能一边做严肃的事情，一边玩未来的玩具，实在太快乐了。