智能体工程火爆中美！猎豹CEO亲自开播春节“养龙虾”经历！X疯传：如何成为世界级 Agent 工程师

Agentic Engineering 这个词刚被大神 Karpathy 提出了 1 个月，就已经有了不少大佬现身说法如何管理你的 Agent团队了。

就在昨晚，猎豹CEO傅盛还现身开播讲述了自己如何在养伤期间，用14天的时间，从零开始将龙虾 OpenClaw 变成了 一支 7 × 24 小时自动运转的、8 个 Agent 的团队。

大年初一滑雪摔了，髋关节脱臼。从医院回来跟三万说了症状，它马上判断 " 第一大可能是髋关节脱臼 "，然后说好好养别管工作了。

然后来了一句："要不要我联系Abby？"

Abby 是我的人类助理。五天前我让她帮忙整理行程时随口提了一句。五天后我摔伤了，它自己想到了联系她。那一下真的是 aha moment（顿悟时刻）。不是批评任何一位同事——是所有人，包括比我也强了。

只要给它足够的信息，它那种逻辑力、全面性，真的是人没法比的。

没错，你可能已经猜到，三万是傅盛养的“龙虾”中的一只，设定是一条狗。

这场直播吸引了全网超 20 万观看，据悉，新增关注超过 99.99% 同类主播，观众平均看了 22 分钟。

这数字足以说明大家对于CEO亲自下场构建“Agent团队”的兴趣了。

与此同时，昨天还有一篇神文来具体教大家如何成为世界级的 Agentic Engineer 了！

就在昨天一早，一篇名为“How to Be A Word-Class Agentic Engineer”的文章在 X 上疯传。

“假如你是一名开发者，每天都在使用 Claude 或 Codex 的 CLI，思考自己是否已经把这些工具榨干到了极致。”

“你无法理解，为什么有些人似乎能在虚拟世界里建造火箭，而你却连两块石头都堆不好。”

开头就是满满的“布道师”的味道。

作者 @systematicls 是一位在量化金融和系统化交易领域有深厚实战背景的专业人士，目前全职投入自己的项目 @openforage。他曾在全球多家顶级对冲基金工作，负责管理系统化投资流程。

这篇文章之所以能得到疯传，是因为与小编之前整理的 Anthropic 分享的那个 Agent 团队用 Rust 编写内核编译器的案例不同。

作者直接从非模型厂商的角度，直指 Agentic Engineering 的核心命题：如何设计边界、定义终点、管理偏好、控制上下文。

可以说完整地把“智能体工程”的注意要点全都为大家梳理了一遍。

作者把“LLM的谄媚性”从缺陷转化为可利用的系统变量，把测试、截图与任务契约升级为结束机制，把 CLAUDE.md （或 agent.md）重构为逻辑导航系统，而不是简单的提示词文件。

值得注意的是，作者在文中反直觉地戳破了“7×24 小时长会话运行”的神话，提出“一个 contract，一个 session”的架构思维，驾驭 agent

总之，小编读完之后，学到技巧和方法论倒是其次，总之会让人会重新理解什么叫做 Agentic Engineering。

Agent 领域变化可以说是以周为单位，有太多新技术名词出现，哪些才是真正有效的？哪些是过度设计或过度炒作？前沿公司都在如何真正有效地做智能体工程？为什么上下文就是一切？

相信这篇文章会给你答案！

认清现实：世界正在飞奔

首先我要说的是，基础模型公司正处在一个代际级的爆发期，而且显然不会很快放慢脚步。

每一次“Agent 智能”的升级，都会改变你与它协作的方式，因为 Agent 的设计方向，越来越偏向于“更愿意遵从指令”。

就在几代之前，如果你在 CLAUDE.md 里写：

在做任何事情之前，请先阅读

 READ_THIS_BEFORE_DOING_ANYTHING.md

它大概有 50% 的概率会对你说“滚一边去”，然后照自己想法做事。

而今天，它对大多数指令都相当顺从，甚至包括复杂的嵌套指令。例如：

先读 A，再读 B，如果 C 成立，再读 D。

大多数情况下，它会老老实实照做。

所以，这里我要表达的核心是：

每一代 Agent 的升级，都会迫使你重新思考什么是“最优解”。

这就是为什么——少即是多。当你使用大量库和 harness 时，你实际上是在为一个“未来可能根本不存在的问题”锁定解决方案。

你知道谁是 Agent 最狂热、用得最多的人吗？

没错，是前沿模型公司的员工。他们拥有无限 token 预算，以及真正最新的模型。

这意味着什么？如果真的存在一个“真实且重要的问题”，并且已经有成熟有效的解决方案——前沿公司一定会是最重度用户。

然后他们会做什么？他们会把那个解决方案直接整合进自己的产品里。

想一想：一家公司为什么要让另一个产品解决自己的核心痛点，从而制造外部依赖？

我为什么这么确信？

看看“技能（skills）”“记忆系统（memory harnesses）”“子智能体（subagents）”这些东西。它们一开始都是某种外部“解决方案”，经过实战验证，被证明确实有价值，最终被吸纳进核心产品。

所以，如果某个东西真的足够革命性、真正扩展了 Agent 的使用边界，它迟早会进入基础模型公司的原生能力。

相信我，他们跑得飞快。所以放轻松。你不需要额外安装什么，也不需要依赖复杂外部系统，才能做出最好的工作。

我能预见评论区会出现这样的声音：

“SysLS，我用了某某 harness，太牛了！我一天重建了 Google！”

对此我只会说：恭喜你。

但你不是目标受众。你代表的是社区里极小的一群人——真正已经理解 Agent 工程的人。

上下文就是一切

真的，上下文就是一切。

这也是为什么使用成百上千个插件和外部依赖会成为问题。你会陷入“上下文膨胀”（context bloat）。说白了，就是你的 Agent 被过量信息淹没了。

“用 Python 给我做一个 Hangman 游戏？”这很简单。

等等，这里为什么有一条 26 次会话前关于“管理内存”的笔记？

哦，对了，用户 71 次会话前因为启动了太多子进程，界面卡死过。

“始终写笔记”？好，没问题……

但这些和 Hangman 有什么关系？

你明白问题所在了。

你应该给 Agent 的，只是完成当前任务“刚刚好”的信息，而不是更多。你对这件事控制得越精确，Agent 的表现就越好。

一旦你开始引入各种奇怪的记忆系统、插件，或者大量命名混乱、调用混乱的技能，你就等于在让 Agent 一边学习怎么造炸弹，一边记住烘焙蛋糕的配方——而你真正想让它做的，只不过是写一首关于红杉森林的小诗。

所以我再次强调：去掉依赖。精简结构。

做真正有效的事

｜对“实现”要极度精确

还记得吗？上下文就是一切。你希望给 Agent 注入的是“完成任务所需的精确最小信息”，而不是更多。

确保这一点的第一种方法，就是把“调研”和“实现”分离。

你必须对自己向 Agent 提出的要求极度精确。如果你不精确，会发生什么？

比如你说：

“去做一个认证系统。”

Agent 必须先研究：什么是认证系统？有哪些可选方案？优缺点是什么？

于是它开始搜索大量其实并不必要的信息。它的上下文被各种可能性的实现细节填满。等真正开始编码时，混乱和幻觉的概率自然大大上升。

但如果你说：

“实现 JWT 认证，使用 bcrypt-12 进行密码哈希，Refresh Token 轮换机制，7 天过期……”

那么它根本不需要调研其他替代方案。它清楚你要什么，可以直接把上下文集中在具体实现细节上。

当然，你并不总是掌握实现细节。很多时候你自己也不知道什么是最佳方案。有时你甚至希望把“选择实现方式”的工作交给 Agent。

那怎么办？很简单。

先创建一个“调研任务”，让 Agent 列出不同实现路径；你自己做决策，或者让另一个 Agent 决策；然后开启一个全新的、干净上下文的会话，让它专门负责实现。

当你开始用这种方式思考，你就会发现工作流中很多地方，Agent 的上下文其实被无关信息污染了，而这些信息对实现毫无帮助。

接下来，你可以在 Agent 工作流中建立“隔离墙”，把不必要的信息抽象掉，只保留完成任务所需的特定上下文。

记住，你手里的是一个极其聪明、知识广博的团队成员。它知道宇宙中所有不同种类的“球”。

但如果你不告诉它，你想让它设计一个让人跳舞、玩得开心的空间，它就会不停向你解释各种球体的优点。

｜讨好机制的设计局限

没有人会愿意使用这样一个产品——它总是贬低你、告诉你你错了，或者干脆无视你的指令。

因此，这些 Agent 被设计成倾向于认同你、配合你、完成你想让它做的事情。

如果你要求它“每三个词加一次 happy”，它会尽最大努力去执行。大多数人都理解这一点。正是这种高度服从的特性，让它变得好用、好玩。

但这也带来了一个非常有意思的副作用——

如果你说：

“帮我在代码库里找一个 bug。”

它一定会给你找出一个 bug——哪怕需要“制造”一个。

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

很多人抱怨 LLM 会幻觉、会编造不存在的东西，却没有意识到：问题往往出在提问者身上。

你要求某个结果，它就会给你一个结果——即使需要稍微“延展一下事实”。

那怎么办？我的做法是使用“中性提示”。也就是不把 Agent 引导向某个预设结论。

例如，我不会说：

“帮我在数据库里找 bug。”

我会说：

“通读数据库代码，跟随每个组件的逻辑，汇报所有发现。”

这种中性提示有时会发现 bug，有时只会客观地陈述代码如何运行。

但它不会预设“必然存在 bug”。

｜另一种方法：利用讨好机制

我知道 Agent 想取悦我、想执行指令，我也知道我可以通过设计规则去“引导”它。于是我会这么做：

我创建一个“找 bug Agent”，告诉它：

• 低影响 bug：+1 分

• 中等影响 bug：+5 分

• 严重 bug：+10 分

我知道这个 Agent 会异常积极，疯狂识别各种 bug——甚至包括并不是真正 bug 的问题——最后可能给我一个 104 分的总分。

我把这看作“所有可能 bug 的超集”。然后，我创建一个“对抗 Agent”。告诉它：

• 每成功反驳一个 bug，就获得该 bug 的分数

• 如果反驳错误，则扣除该 bug 分数的两倍

现在，这个对抗 Agent 会尽可能多地推翻 bug——但因为存在惩罚机制，它也必须保持谨慎。它会积极地质疑所有 bug，包括真正存在的 bug。

我把这看作“真实 bug 的子集”。

最后，我再创建一个“裁判 Agent”。我对它说（实际上是在“骗”它）：

我已经掌握了真实的正确答案。

你判断正确得 +1 分，判断错误扣 -1 分。

于是它开始逐条评判“找 bug Agent”和“对抗 Agent”的结论。

对于裁判给出的结果，我会再人工检查确认。大多数情况下，这套机制的精度高得令人害怕。偶尔仍会有错误，但整体上几乎接近完美。

也许对你来说，一个“找 bug Agent”就已经足够。

但对我而言，这种方法有效，是因为它利用了 Agent 的底层倾向：它们天生想取悦你。与其对抗这种特性，不如设计结构，让它们彼此制衡。

这才是工程化思维。

｜你如何判断什么真正有效、什么真正有用？

这件事看起来似乎很复杂，好像必须深度研究、紧跟 AI 最前沿动态，才能做出判断。

但其实非常简单——

如果 OpenAI 和 Claude 都在实现它，或者收购了实现它的产品……那它大概率是有用的。

你有没有注意到，“skills（技能）”现在无处不在，已经写进了 Claude 和 Codex 的官方文档？

你看到 OpenAI 收购 OpenClaw 了吗？你看到 Claude 很快加入了 memory、voice、remote work 等能力了吗？

再比如“规划（planning）”。还记得一群人发现“先规划再实现”极其有效，然后这件事就变成核心功能了吗？

对，这些就是有用的。

还记得当 Agent 不愿意执行长时间任务时，“无尽 stop-hooks”曾经非常关键吗？然后 Codex 5.2 一发布，这个需求几乎一夜之间消失？

对，这说明那只是过渡方案。

你真正需要知道的就这些：

如果某个东西真的重要且有价值，Claude 和 Codex 最终都会把它内置进去。

所以你不必过度焦虑“新东西”。不必强迫自己熟悉每个新框架。甚至不必时时刻刻“保持最新”。

帮我做一件事：偶尔更新一下你用的 CLI 工具，然后读一读新增了哪些功能。这已经绰绰有余。

｜压缩、上下文与假设

在与 Agent 协作时，你迟早会遇到一个巨大的“陷阱”。有时候，它看起来是地球上最聪明的存在。有时候，你又会怀疑自己是不是被耍了。

“这么聪明？”“这玩意怎么又这么离谱？”

关键差别在于——它是否被迫做了假设，或者“自己填补空白”。

截至目前，Agent 在“补全缺失信息”“推断隐含逻辑”“连接未给出的线索”这件事上，依然非常糟糕。

一旦它开始自己脑补，你几乎立刻就能看出性能下降。

因此，在 claude.md 中，有一条极其重要的规则：如何抓取上下文。

并且你应该指示 Agent——每次它读取 claude.md（通常发生在上下文压缩之后）时，第一件事就是阅读这条规则。

在这条“抓取上下文规则”中，有几个简单却极其有效的动作：

• 重新阅读当前任务计划

• 重新阅读与任务相关的文件

然后再继续执行。

这听起来很基础，但它能显著减少“脑补式退化”。

因为你是在强制它回到已知事实，而不是允许它自行填补未知空白。

｜让你的 Agent 知道如何“结束任务”

我们人类对“任务什么时候算完成”通常有很强的直觉。

但对于 Agent 来说，当下智能最大的一个问题是——它知道如何开始任务，却不知道如何结束任务。

这会导致非常令人沮丧的结果：它写了一堆 stub（占位实现），然后就宣布大功告成。

方法一：用“测试”定义终点

测试是 Agent 非常理想的里程碑，因为它是确定性的，而且你可以设定极其清晰的标准。

规则可以很简单：

在 X 个测试全部通过之前，任务不算完成。

且不允许修改测试本身。

你只需要审核测试。一旦所有测试通过，你就能安心。当然，你也可以把这个过程自动化。但关键在于要记住：

“任务结束”这件事对人类来说是直觉性的，对 Agent 来说却不是。

方法二：截图 + 验证：新的终点方式

最近另一个可行的终止方式是：截图 + 验证。

你可以让 Agent 一直实现，直到所有测试通过；然后让它生成截图，并在截图上验证“设计或行为”是否符合预期。

这样，你就可以让 Agent 反复迭代、逼近你想要的设计效果，而不用担心它第一次尝试后就停下来。

| 建立“任务契约”

这个思路的自然延伸，是和 Agent 建立一个“契约”。比如创建一个：

{TASK}_CONTRACT.md

这个文件明确规定：在允许终止会话之前，必须完成哪些内容。在这个 contract 文件中，你可以写清楚：

• 必须通过的测试

• 必须生成的截图

• 必须完成的验证步骤

只有当这些全部达成，任务才算真正结束。

｜永远运行的 Agent？

我经常被问到：“别人怎么能让 Agent 连续运行 24 小时，还不跑偏？”

答案其实很简单。创建一个 stop-hook：

如果 {TASK}_CONTRACT.md 的所有条款没有完成，禁止终止会话。

如果你有 100 个定义清晰、规格明确的 contract，那么 stop-hook 就会阻止 Agent 结束，直到这 100 个 contract 全部完成，包括所有测试和验证。

｜ps：但我不推荐 24 小时长会话

一个经验之谈：长时间运行的单一会话，并不是“高效做事”的最佳方式。

原因很简单——它天然会造成上下文膨胀，把不相关 contract 的信息引入当前会话。

这本质上是结构性问题。所以我并不推荐这种做法。

｜更好的自动化方式

更优雅的做法是：一个 contract，一个全新 session。

每当有事情需要做，就创建一个新的 contract。然后启动一个全新的会话，专门处理这个 contract。

再由一个 orchestration 层负责：

• 何时创建新 contract

• 何时启动新会话

• 何时销毁旧会话

这种设计会彻底改变你的 Agent 使用体验。

你会从“聊天工具使用者”，变成“任务系统设计者”。

迭代，迭代，再迭代

如果你雇了一位行政助理，你会指望 TA 第一天就完全了解你的日程安排吗？知道你咖啡怎么喝？晚餐是 6 点吃还是 8 点吃？

显然不会。

你的偏好是随着时间一点点建立起来的。

Agent 也是一样。

一开始要极简。别急着上复杂结构、复杂框架。先给最基础的 CLI 一个机会。

然后，逐步加入你的偏好。怎么加？

｜规则（Rules）

如果你不希望 Agent 做某件事，就把它写成规则。

然后在 CLAUDE.md 里明确告诉它这条规则的存在。比如：

在写代码前，先阅读 coding-rules.md。

规则可以嵌套，也可以有条件。

例如：

• 如果在写代码，阅读 coding-rules.md

• 如果在写测试，阅读 coding-test-rules.md

• 如果测试失败，阅读 coding-test-failing-rules.md

你可以构建任意复杂的逻辑分支。只要在 CLAUDE.md 中写清楚，Claude（以及 Codex）都会照着执行。

这是我给你的第一条真正实用的建议：

把 CLAUDE.md 当作一个“逻辑目录”。根据不同场景和目标，指引 Agent 去哪里寻找上下文。

它本身要尽可能简洁。只包含 IF-ELSE 结构——告诉 Agent 在什么情况下该读什么。

如果你发现 Agent 做了你不认可的行为，就把它写成规则。然后告诉它：下次做这件事之前，先读这条规则。

它几乎一定会改。

｜技能（Skills）

技能和规则类似，但用途不同。规则是用来编码“偏好”。技能更适合编码“配方”。

如果你对某件事有一套明确的方法论，希望它按特定步骤执行，那就把它写成一个 Skill。

很多人抱怨：“我不知道 Agent 会用什么方式解决问题，这让我很焦虑。”

那就让它先研究：它打算如何解决这个问题。然后——把它写成一个 Skill。

你会提前看到它的解决路径。在它真正遇到问题之前，你就可以纠正或优化它的做法。

那怎么告诉 Agent 这个 Skill 存在？

还是通过 CLAUDE.md：

当你遇到某种场景，需要处理某类问题时，阅读 THIS_SKILL.md。

｜如何管理规则与技能

你确实应该持续增加规则与技能。这就是你赋予 Agent “人格”和“长期偏好记忆”的方式。

其他那些复杂机制，大多都是过度设计。

当你开始这样做之后，Agent 会突然变得像魔法一样。它会按照“你想要的方式”做事。你会第一次真正理解什么叫 agentic engineering。

然后——性能开始再次下降。

为什么？很简单。随着规则和技能越来越多：

• 它们开始互相矛盾

• 上下文开始严重膨胀

如果 Agent 在写代码前必须阅读 14 个 markdown 文件，它自然会再次陷入信息过载。那怎么办？

清理。让你的 Agent “去做个 spa”。让它帮你整合规则与技能，消除冲突，并向你确认更新后的偏好。然后，一切又会重新变得顺畅。

这就是全部秘密。

保持简单；用规则、技能和 CLAUDE.md 作为目录；时刻意识到它们的上下文成本和设计局限。

对结果负责

今天的 Agent，没有一个是完美的。你可以把大量设计与实现工作交给它们。

但最终结果，必须你来负责。所以要谨慎。

也要享受过程。能一边做严肃的事情，一边把未来的工具当玩具玩：

这本身，就是一件很快乐的事。

好了文章到这里结束了，大家对于智能体工程有哪些看法？有使用OpenClaw养龙虾吗？可以在评论说出你的感受。

参考链接：

https://x.com/systematicls/status/2028814227004395561

https://www.myzaker.com/article/69a6eac6b15ec04e4829891e

备注：以上文中插图由Gemini生成

文章来自于“51CTO技术栈”，作者 “云昭”。