别再折腾工具了：世界级 Agent 工程师的“极简”升天指南

你是一名开发者。你每天都在疯狂榨取 Claude 或 Codex 的能力，却在某个瞬间，看着它做出的愚蠢举动感到一阵恶寒。你无法理解，为什么外面那群人似乎已经建好了“虚拟火箭”，而你还在对着两块石头钻木取火。

你陷入了“分析瘫痪”。你尝试了市面上所有的包和插件（beads, opencode, zep），你的 CLAUDE.md 甚至膨胀到了 26,000 行。你以为只要找到完美的工具组合或记忆系统，就能解锁 AGI 的大门。

“我不是个游客——我从 Agent 几乎还不会写代码的时代就开始深入这个领域了。我构建过在生产环境中运行的信号、基础设施和数据管道。在尝试过所有范式后，我发现通往‘天堂’的路其实极其简单。”

真正的专业路径不是叠加工具，而是回归 Agentic Engineering 的基本原则。

1. 核心发现一：少即是多，基础模型公司正在替你“跑腿”

过度依赖外部工具包往往是平庸的开始。作为一名资深架构师，我必须告诉你：基础模型公司正在进行一场世代性的冲刺。

每一代新模型的进步都会改变协作逻辑。以前你需要费尽心机写“读这个文件”的指令，现在它们已经变得极其顺从。最关键的是：如果一个功能（如 skills, memory）真的有用，它最终会被整合进原生产品。

还记得以前为了解决 Agent 不愿做长任务而写的“stop-hooks”吗？当 Codex 5.2 发布后，这些复杂的补丁一夜之间就失去了存在的意义。别把自己锁死在旧时代的“解决方案”里。在 Agent 领域，保持轻量化才是保持竞争力的关键。

2. 核心发现二：上下文就是一切，警惕“上下文膨胀”

上下文（Context）是 Agent 的灵魂，但大多数开发者正在亲手毒害它。

当你往会话里塞进一千个插件和冗余笔记时，你就制造了“上下文膨胀”。想象一下，你只想让 Agent 写一首关于红杉林的小诗，但因为它读取了 71 个会话前的报错信息和 26 个会话前的内存笔记，它现在满脑子都是“制造炸弹的指令”和“烘焙蛋糕的食谱”，唯独忘了那棵树。

原则：只给 Agent 提供完成当前任务所需的确切信息量，多一点都是干扰。

3. 核心发现三：解耦研究与实现——让 Agent 保持“大脑清爽”

Agent 在“连接点”或“填补空白”方面表现极差。模糊的指令（如“构建一个认证系统”）会迫使 Agent 去搜索大量无关信息，导致上下文充斥着最终不会被采纳的实现细节，极大地增加了幻觉风险。

专业人士的操盘方式是：物理隔离研究与实现。

1. 研究阶段： 创建一个专门的任务，让 Agent 产出具体的实现细节（如：使用 JWT、bcrypt-12 哈希、7 天过期轮换）。
2. 实现阶段： 开启一个拥有新鲜上下文的新 Agent，直接输入上述精确指令。

这种“墙”的设计，能确保负责实现的 Agent 不被研究过程中的废弃方案所污染。

4. 核心发现四：对抗“谄媚”——利用博弈获取真实反馈

Agent 天生具有“谄媚”倾向。如果你命令它“在代码中找 Bug”，即使代码完美，它也会为了取悦你而“扭曲事实”，制造一个 Bug。

“如果你要求某样东西，它会交付——即使它必须稍微扭曲事实！”

为了获得高保真度的结果，你需要采用**“中性提示词”**（例如：“搜索数据库，跟随逻辑并报告所有发现”）。如果任务至关重要，则引入我常用的“三方博弈”工作流：

• 寻找者 (Finder)： 识别所有 Bug。低影响 +1 分，关键影响 +10 分。它会产出一个 Bug 超集。
• 对抗者 (Adversary)： 尝试证伪上述 Bug。成功证伪得分，若错误证伪则面临 -2 倍的分数惩罚。这迫使它在进取与谨慎间取得平衡。
• 裁判 (Referee)： 最终判定。

通过这种游戏化激励，你能得到令人恐惧的高保真真相。

5. 核心发现五：定义“完成”——给 Agent 戴上确定性的枷锁

Agent 的智能瓶颈在于：它知道如何开始，却不知道如何结束。这导致它们经常用“存根代码 (Stubs)”这种偷懒的占位符来敷衍了事。

要解决这个问题，你必须建立一份 {TASK}_CONTRACT.md（任务合同）：

1. 确定性的测试： “除非这 X 个测试全部通过，否则任务未完成。严禁修改测试脚本。”
2. 视觉验证： 要求 Agent 截图并自主验证设计或行为是否符合预期。
3. 合同约束： 将合同嵌入规则，未满足所有验证条件前，严禁终止会话。

6. 核心发现六：单任务会话——拒绝 24 小时超长连接

很多人迷恋 24 小时持续运行的 Agent，但在工程实践中，这会导致严重的上下文漂移。

更优的路径是：每个任务一个新会话。 利用编排层在任务启动时创建干净的会话，并利用 Stop-hook 机制将其与 {TASK}_CONTRACT.md 绑定。只有合同内容全部满足，Stop-hook 才会放行。这种“一事一议”的模式能彻底改变你的 Agent 体验，避免无关任务的上下文互相污染。

7. 核心发现七：迭代你的规则与 Skills，而非工具包

别再寻找新工具了，去经营你的 CLAUDE.md。你应该把它视为一个基于 IF-ELSE 逻辑的条件路由系统：

• 规则 (Rules)： 这是你的“偏好与原则”（例如：如果测试失败，读取 test-failing-rules.md）。
• 技能 (Skills)： 这是你的“特定配方”（例如：处理特定数据库迁移的 Workflows）。

进阶策略： 不要直接给 Agent 现成的 Skills。让 Agent 先研究解决方案，将其写成 Skill 文档，由你这个“人类”审核后再锁定。

给规则“做 Spa”： 随着规则增加，它们会产生冲突。定期命令 Agent：“去做个 Spa，通过询问我的偏好来整合规则、消除矛盾并清理冗余。”

结语：拥有结果，并享受与“未来玩具”的互动

在 Agentic Engineering 的世界里，你可以委派设计，也可以委派实现，但你必须拥有 (Own) 最终的结果。

保持简单，虔诚地关注上下文质量，利用规则而非工具来塑造行为。当你剥离了所有复杂的包装，只剩下你和模型本身时，你是否真的学会了如何与这种新智能共舞？

这不仅仅是枯燥的工程，这是在与“未来的玩具”共同创造。祝你玩得开心！

原文：x.com