TECH

AI 协作的大道至简：五条心法，把 Agent 用到极致

不追新、不堆工具、不写两万行配置——从上下文管理到验收合同，五条可复用的心法帮你搭建真正有效的 AI 工作流。

来源： @systematicls on X / AGI知路

修订记录

先看结论

1. 别追工具，追原理。基础模型每一代都在把第三方方案吃掉，你今天精心搭建的”最优工具组合”，下一代模型可能直接自带。
2. 上下文是 Agent 表现好坏的第一变量。只给当前任务刚好需要的信息，多一条规则都是噪声。
3. 研究和实现必须物理隔离。用不同会话做选型调研和写代码，让每个 Agent 只看到自己需要的东西。
4. 给 Agent 一条可验证的终点线。测试用例、截图验证、任务合同——不是 Agent 说”完了”就完了，而是合同条件全部满足才算交付。
5. 用规则和技能慢慢养工作流。不要一步到位，从最简配置开始，一条条加规则，一个个加技能，定期清理。

如果你只有两分钟，记住前两条就够了。下面展开说为什么，以及怎么做。

Why：你可能在用最笨的方式使用最聪明的工具

装了十几个插件、写了两万行 CLAUDE.md、把市面上所有 Agent 框架试了一遍——然后发现别人用最基础的 CLI 反而做得更好。这种落差并不罕见。

问题出在哪？不是工具不好，而是信息过载让 Agent 变笨了。

这就好比你让一个人写一首关于红杉林的小诗，同时塞给他一份炸弹制造手册和一份蛋糕烘焙配方。信息越杂，Agent 越不知道该关注什么，输出质量也就越不稳定。

真正的 Agentic Engineering 不是做加法，而是做减法。下面五条心法，就是这个减法哲学的具体落地。

心法一：少堆工具，信任基础模型的进化速度

如果一个功能真的重要，基础厂商迟早会把它做成原生能力。

回头看这几年的演进：技能（Skills）、记忆管理（Memory）、子 Agent（Sub-agents）、规划能力（Planning）——每一个都先从第三方”解决方案”起步，被验证有效后，迅速成为大模型的原生功能。

反面的例子也有：当年因为 Agent 不听话而流行的 stop-hook 机制，在某次模型更新后一夜之间就失去了意义，因为新模型自己就能完成长周期任务。

这意味着什么？

• 你搭的”最优解”有保质期。用了太多第三方库和框架，就是把自己锁死在针对旧问题的方案里。
• 最大的工具使用者是厂商自己的员工。他们有无限 token 额度和最新模型。如果真有痛点和好方案，厂商不会放任外部依赖——他们会直接集成。
• 你需要做的很简单：偶尔更新一下 CLI 工具，读一下新增了什么原生功能，就够了。

这不是说所有第三方工具都没用，而是说：在追新之前先问自己，这个问题下一代模型会不会直接解决？ 如果答案可能是”会”，那就别急着引入新依赖。

心法二：上下文就是一切

这是整套方法论的第一性原理。Agent 的输出质量，几乎完全取决于它当前上下文里装了什么。

上下文膨胀的典型症状

• CLAUDE.md 写了几千行，Agent 每次启动都要”消化”一遍。
• 插件和记忆系统自动注入了大量与当前任务无关的历史信息。
• 一个长会话里混杂了多个不同任务的上下文，Agent 越到后面越跑偏。

怎么做

原则只有一条：只给 Agent 完成当前任务刚好需要的信息，多一个字都不要。

具体来说：

1. CLAUDE.md / AGENTS.md 做成导航目录，不堆内容——只写”在什么场景下，去读哪个文件”。
2. 规则按场景分文件，而不是全写在一个大文件里。比如：写业务代码读 coding-rules.md，写测试读 test-rules.md，排障读 debug-rules.md。
3. 长会话是上下文膨胀的温床。一个任务结束后，开一个全新的干净会话。

在我自己的实践中，这一条的效果最立竿见影。当我把 AGENTS.md 从”大杂烩文档”重构为”场景导航 + 外链规则文件”的结构后，Agent 的遵令率和输出质量明显提升——因为它每次只需要读与当前任务相关的那几个文件。

心法三：研究与实现分离

这是上下文管理的第一个实战推论。

反面案例

“给我做一个用户认证系统。”

Agent 看到这个指令会怎么做？先调研认证方案有哪些，对比 JWT、OAuth、Session 的优缺点，可能还去搜了一圈最佳实践……等它终于开始写代码，上下文里已经塞满了各种方案的实现细节，出错和幻觉的概率直接拉满。

正面案例

“实现 JWT 身份认证，使用 bcrypt-12 做密码哈希，刷新令牌有效期 7 天，支持自动轮换机制。”

Agent 不需要做任何选型调研，它清楚地知道要实现什么，上下文里只有与这个具体方案相关的信息。

具体怎么拆

1. 会话 A（研究）：让 Agent 调研、对比方案、给出选型建议。你审核并拍板。
2. 会话 B（实现）：开一个全新的空白会话，只把最终确定的实现要求给它。

这看起来多了一步，但实际效率远高于在一个混乱的上下文里反复修正。

我自己在做产品设计时踩过一个坑：有一个模块我没有经验，直接让 AI 帮我设计，结果方案看起来合理，落地时完全不对。后来换了思路——先让 AI 做竞品分析，输出选型建议，我确认后再开新会话实现——效果好了一个量级。本质上就是研究和实现分离的原则。

这给了我一个更深的体会：在 AI 能力不断升级的当下，个人能力的核心不是”我自己能做什么”，而是”我能不能找到好方法，让 AI 发挥它的能力”。 这个方法，就是 spec-driven——通过明确的 spec 约束 AI 的输出范围，让它在清晰边界内发挥创造力。

心法四：用验收合同定义终点

人类天然知道一个任务什么时候算”完了”，但 Agent 不知道。它知道怎么开始，却常常不知道怎么结束——写了几个空函数、空接口就觉得交差了。

三层终点设计

第一层：测试用例做硬里程碑。

提前写好测试，告诉 Agent：“这些测试不全部通过，任务就不算完成，且你不允许修改测试。” 你只需要审核测试用例本身就好，测试通过即交付。

第二层：截图 + 行为验证。

对前端和交互类任务，让 Agent 实现完后自动截图，基于截图验证界面和行为是否符合要求。不符合就继续迭代。

第三层：任务合同（Contract）。

把所有验收标准写进一个 {TASK}_CONTRACT.md 文件：

• 要通过的测试
• 要验证的截图
• 要满足的功能点
• 要交付的文件

明确告诉 Agent：合同里的要求没有全部满足，不许结束会话。

一个重要纠偏

很多人追求”24 小时不中断的长会话”，觉得越长越厉害。实际上长会话天生就会带来上下文膨胀——不同任务的合同、信息混在一起，Agent 很快就会跑偏。

更好的方式是：一个合同，一个全新会话。 用一个简单的编排层来管理合同的生成和会话的创建。这样每个任务都有干净的上下文，效率和准确率都会提升一个量级。

心法五：用规则和技能，慢慢养出你的工作流

Agent 不会在第一天就知道你所有的偏好，就像你不会指望一个新来的助理第一天就知道你几点吃晚饭。正确的做法是：从极简开始，一点点加。

规则：定”红线”和偏好

如果 Agent 做了你不喜欢的事，就写成一条规则。规则可以嵌套、可以有条件分支：

- 如果在写业务代码 → 先读 coding-rules.md
- 如果在写测试 → 先读 test-rules.md
- 如果测试挂了 → 先读 debug-rules.md

核心建议：把 CLAUDE.md 做成逻辑清晰的导航目录，只写场景 → 规则文件的映射，不堆内容。

技能：固化”做事菜谱”

规则管”不能做什么、按什么习惯做”，技能管”具体这件事按什么流程做”。

如果你有一套成熟的开发流程（接口开发标准步骤、故障排查固定流程、数据管道搭建规范），就写成技能文档。在 CLAUDE.md 里注册：“遇到 X 场景，先读 X-SKILL.md，按里面的流程执行。”

还有一个更妙的用法：如果你不确定 Agent 会怎么解决一个问题，就先让它把解决思路写成技能文档。 你审核、修改、确认后，以后它遇到同类问题就必须按审核过的流程执行。这样，Agent 的行为就变得可预期、可复用。

定期清理，避免规则膨胀

规则和技能越加越多，Agent 反而变笨了？大概率是规则之间开始矛盾，或者读取的文件太多导致上下文膨胀。

解决办法：定期让 Agent 做一次”大扫除”——把所有规则和技能丢给它，让它整合、去重、标记矛盾，遇到歧义就问你最新的偏好。

清理完之后，你会发现 Agent 又回来了。

实战：我刚对自己的项目做了一次”大扫除”

写完上面的心法之后，我回头审视了自己项目的 AGENTS.md、copilot-instructions.md 和 5 个技能文档，发现正好踩中了上面说的每一个坑。下面是这次清理的完整记录，你可以拿来作为自己项目的清理模板。

诊断：发现了什么问题

1. 同一信息重复出现在多个文件。

“中文沟通，英文标识符”这条规则，同时写在了 AGENTS.md 和 copilot-instructions.md 里。“WSL/Linux 执行基线""提交前验证命令""字体冻结护栏”也是如此。Agent 每次启动要读两个文件，等于同样的信息灌了两遍。

更严重的是，AGENTS.md 里有整整一个章节（“技术教程写作护栏”），和 tech-tutorial-writing/SKILL.md 几乎逐字重复。触发技能后又读第三遍——这就是教科书级的上下文膨胀。

2. 导航文件塞了太多实现细节。

“公众号原文抓取”和”内容导入”两节，不仅写了触发条件，还把入口命令、参数、降级策略全写了一遍——但这些信息在 SKILL.md 里已经有完整版。按”导航目录”原则，AGENTS.md 只需要写”什么场景 → 去读哪个 SKILL.md”就够了。

3. 有一个技能极度特化，几乎不会再触发。

有个写作技能是专门为”春晚/奥运等大型公共文化事件的逐节目卡片长文”设计的。除非每年写一篇类似稿件，否则它只是占着技能菜单的一行噪声。

4. 通用技能里残留了特定文章的术语。

技术教程写作技能的”下沉规则”里写着 rootful/rootless、socket/context、core/extended——这些是从某篇 Podman 教程直接搬来的，不是通用规则。新文章触发这个技能时，这些术语就是无关噪声。

动手：具体改了什么

清理后，Agent 每次启动读取的总文本量减少了约 40%，且所有重复信息源全部消除。

你可以复用的清理清单

下次觉得 Agent”变笨了”，试试按这个顺序检查：

1. 查重复：AGENTS.md / CLAUDE.md 和各 SKILL.md 之间有没有逐字重复的段落？有就只留一份，另一处改为导航链接。
2. 查膨胀：导航文件里有没有本该只在 SKILL.md 里出现的实现细节（命令、参数、降级策略）？有就搬走，只留触发条件。
3. 查死技能：有没有极度特化、过去 30 天从未触发的技能？有就归档或删除。
4. 查残留术语：通用技能里有没有某篇文章专属的术语？有就泛化为通用描述。
5. 查矛盾：不同文件对同一件事（如”口吻""第一人称”）的要求是否方向相反？有就明确优先级或合并。

每次清理完，跑一遍构建验证，确认没有破坏任何东西。

这个清理过程本身，就是心法二（控上下文）的最佳实践。

我的平衡点：spec-driven，但不过度控制

写到这里，可能有人会问：按这套心法做，是不是每个任务都要人工写 spec、写合同、写规则？那不是回到了”过度控制”的极端？

确实有这个风险。在我自己的实践中，人和 AI 的协作有一个平衡点：

• 过度放任：直接让 AI 从零开始，结果不符合预期，后面大量返工。
• 过度控制：每一步都人工干预，AI 一遍就能做对的事也要你逐行审核，效率极低。

这个平衡点没有固定答案，因为 AI 的能力在不断变化，工具也在迭代。今天在设计层面需要你写清楚 spec 的事，明天可能 AI 自己就能做好。

所以我给自己定的原则是：

1. 在 AI 不擅长的地方写 spec（产品设计、业务逻辑、验收标准），在 AI 擅长的地方放手（具体实现、代码生成、格式化）。
2. spec 的精度跟着模型能力走。模型越强，spec 可以越粗；模型越弱，spec 要越细。
3. 保持学习姿态。如果所有事都让 AI 做，最终产品出来了，但使用 AI 的人落伍了。要有意识地在过程中让 AI 帮你学东西，而不只是帮你做事。

这第三点也许是最容易被忽略的：AI 之路不只是效率之路，也是成长之路。

总结：五条心法一张表

最后一句话：你不需要成为工具专家，你需要成为上下文管理专家。 当你真正掌握了”给 Agent 刚好需要的信息”这件事，工具选什么反而不那么重要了。

参考材料：

• @systematicls, “How To Be A World-Class Agentic Engineer”（X 长文，2026-03-03）
• AGI知路, “如何成为顶级的 Agentic 工程师：AI Coding的大道至简”（公众号，2026-03-05，对上述 X 长文的中文解读）