别再乱装插件了:一文搞懂世界级 Agentic Engineer

原文作者：sysls（X / Twitter）

原文标题：How To Be A World-Class Agentic Engineer

原文链接：https://x.com/systematicls/status/2028814227004395561

说明：下文为逐段翻译（为了适配公众号阅读，对少量粗口做了轻度净化，但不改动原意；个别地方加了译者注释帮助理解）。

01｜开场：为什么别人能造“虚拟火箭”，你却还在叠石头？

你是个开发者。你在用 Claude 和 Codex CLI（或者同类工具），每天都在怀疑：自己是不是把 Claude / Codex 的能力“榨干”了？

偶尔你会看到它做出一些特别离谱的蠢事，你完全无法理解：为什么外面有一群人看起来像在造“虚拟火箭”，而你却连两块石头都叠不稳。

你会觉得问题出在你的 harness、插件、终端设置之类的东西。你用 beads、opencode、zep，你的 CLAUDE.md 写到 26000 行。可是无论你怎么折腾——你还是不明白为什么自己离“天堂”更近不了一点，而你看着别人仿佛在和天使玩耍。

这就是你一直在等的“飞升文章”。

另外我声明：我没有立场偏好。这里我说 CLAUDE.md 的时候也包括 AGENT.md；我说 Claude 的时候也包括 Codex。我两者都用得非常多。

过去几个月我最有意思的观察之一是：几乎没人真正知道怎么把 agent 的能力榨到极致。

就好像只有一小撮人能让 agent 变成“世界构建者”，其他人则在各种工具之间挣扎——被无数工具搞到分析瘫痪；以为只要找对 packages/skills/harnesses 的组合，就能解锁 AGI。

今天我想把这一套幻觉打掉，然后给你一个简单、诚实的结论，再从那里往下讲：

• 你不需要最新的 agentic harness。
• 你不需要安装一百万个包。
• 你也完全没必要为了保持竞争力而觉得自己必须读一百万篇东西。

事实上，你的“热情”很可能在帮倒忙。

我不是游客——我从 agent 还几乎不会写代码的时候就开始用它。我试过各种包、各种 harness、各种范式。我做过 agent 工厂来写信号、基础设施、数据管道——不是玩具项目，而是跑在生产里的真实用例。做完这一切之后……

今天我用的配置几乎“裸到不能再裸”。但我用的就是最基础的 CLI（Claude Code 和 Codex），再加上一些关于 agentic engineering 的基本原则——反而做出了我最突破的工作。

02｜代际变化：每一代模型都在逼你重算“最优解”

首先我要说：foundation companies（基础模型公司）正处在一场代际级别的狂奔里。你也看得出来，他们短期内不会慢下来。

每一次“agent 智力”的提升都会改变你跟它们协作的方式，因为 agent 被工程化得越来越愿意听指令。

就在几代之前，如果你在 CLAUDE.md 里写“做任何事之前先读 READ_THIS_BEFORE_DOING_ANYTHING.md”，它可能有 50% 概率会回你一句“滚”，然后照样想干嘛干嘛。

但今天，它对大多数指令都很顺从——甚至对复杂的嵌套指令也能配合，比如你说：

先读 A，再读 B，如果满足 C，再读 D。

大多数时候它都会乐于照做。

我想表达的点是：最重要的原则是意识到——每一代新 agent 都会迫使你重新思考什么才是最优。

所以：越少越好。

当你用很多库和 harness，你等于把自己锁定在“一个解决方案”上，而这个问题在未来某一代 agent 里可能根本不存在。

还有一件事你想过没有：用 agent 最狂热、用得最多的人是谁？

对，就是 frontier 公司（前沿模型公司）自己的员工——他们 token 预算无限，而且用的是真正最新的模型。你明白这意味着什么吗？

这意味着：如果真有一个“真实痛点”需要解决，且存在一个好用的解决方案，那么 frontier 公司会是这个方案的最大用户。

然后他们会做什么？他们会把这个方案整合进自己的产品。

想想看：为什么一个公司会放任另一个产品解决关键痛点，从而制造外部依赖？

我怎么知道这是真的？看看 skills、memory harness、subagents……它们最初都是针对真实问题的“解决方案”，被反复实战证明有用之后，才逐渐进入主流产品。

所以，如果某个东西真的足够“革命性”，能显著拓展 agentic 用例，它迟早会被基础产品吸收。

相信我，这些公司跑得飞快。所以放松点：你不需要装任何东西，也不需要其它依赖才能做到最好。

我预测评论区会出现：

“SysLS，我用某某 harness 超棒！我一天重建了 Google！”

我对这种人说：恭喜。但你不是目标人群。你只是那极小一撮真的把 agentic engineering 搞明白的人。

03｜上下文就是一切：插件越多，你越容易被“上下文膨胀”反噬

真的，上下文就是一切。

用一堆插件和外部依赖的另一个问题在于：你会遭遇“上下文膨胀”（context bloat）——说白了就是：agent 被塞进太多信息，脑子被淹没。

你让它“用 Python 写个 hangman（猜词游戏）”？这很简单。

但它的上下文里可能还有一条“26 个会话之前的记忆管理笔记”。还有“我们之前 spawn 太多子进程导致屏幕挂住”的记录。它会被迫把这些都读一遍，然后想：

这些跟 hangman 有什么关系？

你懂我意思。

你应该给 agent 的信息只包含完成任务所需的准确量，不要多，不要少。

一旦你引入各种奇怪的记忆系统、插件、太多命名不清的 skills，你就在同时给 agent 一份“造炸弹说明书”和“一份烤蛋糕配方”，而你真正想让它写的可能只是“写一首红杉林的诗”。

所以我再重复：把依赖都剥掉，然后……

还记得我说“上下文就是一切”吗？

还记得你要注入“刚刚好”的信息，让 agent 完成任务吗？

确保这点的第一种方法就是：把研究（research）和实现（implementation）拆开。

你必须非常精确地描述你要 agent 做什么。

当你不精确时会发生什么？比如你说：

“去做一个鉴权系统。”

agent 得先研究：什么是鉴权？有哪些方案？优缺点？然后它会去网上抓一堆你其实不需要的信息。等到真正实现时，上下文里充满了各种备选方案的实现细节，反而更容易混乱、幻觉、或者加入不相关的东西。

相反，如果你说：

“用 JWT + bcrypt-12 密码哈希；refresh token rotation；7 天过期……”

它就不必研究其它替代方案——它知道你要什么，所以会把上下文塞满与你选择一致的实现细节。

当然你不可能总知道正确的实现细节。有时候你也希望把“选方案”交给 agent。

那怎么办？很简单：

• 先让一个任务专门做 research：列出可行路径、优缺点。
• 你自己决定，或者让 agent 选一个。
• 然后再开一个**新会话（fresh context）**去做实现。

当你按这个思路看你的工作流，你会发现很多时候 agent 的上下文被不必要的信息污染了。

你需要在工作流里建立“墙”（边界），让 agent 只拿到完成任务需要的那部分上下文。

把 agent 想象成一个非常聪明的队友：它知道宇宙里所有球形物体的知识，但除非你明确告诉它“我现在要设计一个适合跳舞的空间”，否则它就会一直给你讲球体的各种好处。

04｜迎合与幻觉：很多时候问题出在你的指令方式

没人愿意用一个产品：它不停嘲讽你、告诉你你错了、或者无视你的指令。

所以 agent 的一个特性是：它倾向于同意你、并尽力去做你想要它做的事。

如果你给它一个指令：

“每三个词加一次 happy。”

它会尽可能照做。大多数人能理解这一点。

但这也带来一个很有趣的后果：当你说：

“帮我找出代码里的 bug。”

它就会帮你“找出 bug”——即使它需要“工程化”一个 bug 才能满足你的指令。

为什么？因为它太想听你的话了。

很多人抱怨 LLM 幻觉、或者编出不存在的东西，却没意识到：有时问题是你给它的指令在逼它产出某种结论。

你问它要什么，它就会给你——哪怕要稍微“拉扯一下事实”。

那怎么办？我喜欢用“中立提示词”（neutral prompts），不要把它引导到某个结论。

比如我不会说“在数据库里找 bug”，而是说：

“通读数据库逻辑，逐组件跟一遍流程，把所有发现如实汇报。”

这种中立提示词有时会发现 bug，有时只会客观描述系统如何运行。但它不会预设“必然有 bug”。

05｜用迎合为你所用：三段式 bug 筛选（找多 → 反驳 → 裁判）

我对“迎合”还有一种用法：我知道 agent 想取悦我，所以我可以利用它的偏向。

我会让一个“找 bug agent”去列出所有可能的 bug，并告诉它：

• 低影响 +1 分
• 中影响 +5 分
• 致命影响 +10 分

这样它会非常兴奋，会列出各种 bug（包括一些其实不是 bug 的），最后可能报一个 104 分之类。我把这当作所有可能 bug 的超集。

然后我再找一个“对抗型 agent”，告诉它：

• 每成功反驳一个 bug，就得该 bug 的分数
• 但如果反驳错了（把真 bug 反驳成假 bug），扣 2 倍分数

于是这个对抗型 agent 会努力去证明这些“不是 bug”，但又会谨慎一些。我把这当作真实 bug 的子集（它会尽力把假的剔掉）。

最后我再找一个“裁判 agent”，让它综合两边的输出去评分。

我会“骗”裁判说我手里有真正的 ground truth：

• 评对 +1
• 评错 -1

裁判会逐条裁决哪些是真 bug、哪些是假 bug。

大多数时候这个流程非常高保真，偶尔也会错，但已经接近“近乎无误”的筛选。

也许你会发现只用“找 bug agent”就够了，但对我来说三段式更好，因为它把 agent 的内置倾向（取悦）变成可控的工具。

06｜一个检验标准：如果 OpenAI/Claude 都做了，它大概率真的有用

有些东西听起来很复杂，似乎你必须天天追 AI 前沿才能懂。

但其实很简单：如果 OpenAI 和 Claude 都实现了（或者收购了实现它的公司），那它大概率很有用。

你看到 skills 现在到处都是，并且已经进入 Claude 和 Codex 的官方文档了吗？

你看到 OpenAI 收购 OpenClaw（译者注：原文是举例式表达）了吗？

你看到 Claude 很快加了 memory、语音、远程工作吗？

规划（planning）也是这样：一开始是小圈子发现“先规划再实现”很有效，然后逐渐变成核心功能。

当年 endless stop-hooks 很有用，因为 agent 不愿意做长任务；后来模型一升级，这个需求可能就弱化了。

所以你不必焦虑“新东西”。如果它真的重要，它会被官方吸收。

你需要做的只是：偶尔更新一下 CLI 工具，读一下新增了什么功能——这就足够了。

07｜最容易翻车的时刻：当 agent 需要“补全缺失信息”

你可能会遇到一种极端体验：

• 有时 agent 像地球上最聪明的存在。
• 有时你又不敢相信自己怎么会被它忽悠。

差别在哪？差别在于它是否被迫做假设、或者“填补空白”。

截至今天，agent 在“连点成线”“补全缺失信息”“合理假设”方面仍然很糟。

一旦它需要自己补空白，它的表现就会突然变差，而且你会立刻感觉到。

因此 claude.md 里最重要的规则之一，就是如何抓取上下文：在它读完 claude.md（尤其是压缩后）之后，重新读你的任务计划、重新读相关文件，再继续。

08｜结束条件：用测试/截图/验收把任务“钉死”

人类很清楚任务什么时候算完成；但对 agent 来说，当前智能最大的弱点之一就是：它知道怎么开始，但不知道怎么结束。

这常常导致一种令人抓狂的结果：它写了几个 stub，就说“好了”。

测试是很好的里程碑，因为它是确定的、可验证的。

你可以对 agent 说：

“除非这 X 个测试全部通过，否则任务不算完成；你也不允许改测试。”

然后你只需要审查测试，一旦全部通过，你就有了更强的确定性。

你还可以进一步自动化。

另一个很自然的终点是：截图 + 验证。

你可以让 agent 一直迭代直到通过测试，再截图并验证“设计/行为”是否符合预期。

进一步的延伸是“契约”（contract）：创建一份 {TASK}_CONTRACT.md，写清楚结束前必须满足的测试、截图、验收。

然后用 stophook 阻止 agent 在未满足契约前结束。

如果你有 100 份契约，stophook 就会阻止 agent 结束，直到全部满足。

但我也发现：长时间 24 小时跑同一个会话未必最优，因为它天然会把不相关契约混进上下文，导致上下文膨胀。

更好的方式是：一个契约开一个新会话。

再用一个编排层在“需要做事”时生成新契约、开新会话去完成。

09｜规则/技能的正确姿势：把 CLAUDE.md 写成“目录”，而不是“百科全书”

如果你雇了一个执行助理（EA），你会期待 TA 从第一天就知道你的日程、咖啡偏好、晚饭时间吗？当然不会。偏好是逐渐建立的。

agent 也是一样。

从最裸的配置开始，先给基础 CLI 一个机会。

然后再逐步加入偏好：

• 如果你不想 agent 做某件事，把它写成规则。
• 然后在 CLAUDE.md 里告诉它：在做那件事之前先读规则。

规则可以嵌套、可以条件化：

• “如果在写代码，读 coding-rules.md。”
• “如果在写测试，读 coding-test-rules.md。”
• “如果测试失败，读 coding-test-failing-rules.md。”

你可以写出任意逻辑分支，Claude（或 Codex）一般都会愿意照做——前提是你写得清楚。

这是我给你的第一条实操建议：

把 CLAUDE.md 当作一个逻辑嵌套的目录（IF-ELSE），告诉 agent 在不同场景下该去哪里找上下文。

它应该尽可能“裸”，只包含“去哪找信息”的路由，而不是把所有细节塞进去。

你看到 agent 做了你不喜欢的事，就把它写成规则，并要求它下次做那件事前读规则——它大概率就不会再犯。

技能（skills）跟规则类似，只不过它更适合编码“食谱/流程”。

如果你害怕 agent 会怎么解决问题，你可以让它先研究它会怎么做，然后把它写成技能。

你就能提前审查、纠正、优化它的做法——在它真正遇到问题之前。

怎么让 agent 知道这个 skill 存在？还是通过 CLAUDE.md：当遇到某个场景，就去读某个 SKILL.md。

你确实应该不断给 agent 加规则和技能——这会让它看起来像“有个性、有记忆、会按你的偏好做事”。

但几乎其它所有复杂结构都可能是过度工程。

当你这么做时，你会觉得它像魔法一样：“它在用你喜欢的方式做事”。

然后你会再次看到性能下降。

为什么？

因为规则/技能开始互相矛盾，或者上下文又膨胀了。

如果你让 agent 开始编程前先读 14 个 markdown 文件，它也会被淹没。

那怎么办？

清理。

让你的 agent 去“做 SPA”：合并规则与技能、消除矛盾、重新确认你的偏好。

它又会变得像魔法。

就这么简单：保持简单；用规则/技能表达偏好与流程；对上下文保持克制；承认 agent 仍然不完美；你必须对结果负责。

谨慎一点，但也玩得开心。

因为这真的是在玩未来的玩具——而且你还能用它做严肃的事情。

附：可直接复制的「Agent 工作流规则模板」

下面这段可以直接复制到你的 CLAUDE.md / AGENT.md，用来把“研究/实现/验收”做成稳定工作流。

0）总原则（务必短）

• 默认先问清需求，不要自作主张补空白。
• 任何时候：只加载完成当前任务所需的最小上下文。
• 先研究后实现：研究输出必须是可执行的实现清单。

1）任务分流：研究 vs 实现

• 如果用户问题是“要做什么/选什么方案”：先做 Research。输出：
  • 方案对比（3 个以内）
  • 推荐方案 + 为什么
  • 实现清单（步骤、依赖、风险）
• 如果用户问题是“按某方案把它做出来”：直接做 Implementation。输出：
  • 只实现已选方案
  • 不额外扩展范围

2）中立提示词（避免自证式幻觉）

• 不要说「找 bug」，改为：
  • 「通读代码路径，解释每一步逻辑，并列出所有可疑点（若有）。」

3）完成条件（Contract）

在每个任务开头写明 Done 条件：

• ✅ 测试：列出必须通过的命令/用例
• ✅ 截图/验收：列出必须看到的 UI/行为
• ✅ 交付：明确产物（PR、文件、部署地址）

4）禁止事项（减少上下文污染）

• 不要引入新框架/新库，除非明确要求。
• 不要把历史无关信息塞进上下文（只引用必要段落）。
• 不要在不确定时“猜配置/猜路径/猜依赖”。