把他的核心观点整理出来，确实有不少东西值得记下来。
别急着装新工具，基础公司在狂奔
一个很容易被忽略的事实：前沿公司（Anthropic、OpenAI）的员工本身就是 agent 最重度的用户，他们有无限 token 预算和最新模型。如果某个问题真的存在好的解决方案，他们会第一时间用上，然后直接整合进自己的产品里。
回想一下：skills、memory、subagents、规划功能——这些都是从社区里的第三方方案开始的，被验证有用之后，直接变成了官方功能。OpenAI 收购 OpenClaw 也是同一个逻辑。
所以结论很简单：你不需要追每一个新工具。偶尔更新一下 CLI，看看加了什么新功能，就够了。那些真正有用的东西，迟早会被整合进基础产品。
每一代新 agent 都会改变你跟它协作的最优方式。几代之前，你在 CLAUDE.md 里写"先读这个文件再做事"，它有一半概率直接无视你。现在它对复杂的嵌套指令都很顺从——你可以写"读 A，然后读 B，如果 C 则读 D"，大多数时候它都会照做。
这意味着当你用太多第三方库把自己锁死在某个方案里的时候，那个方案要解决的问题，可能下一代 agent 根本就不存在了。
上下文就是一切
这可能是跟 agent 协作最重要的一条原则。
你想给 agent 的是完成当前任务所需的精确信息量，不多不少。一旦引入各种内存系统、插件、命名混乱的 skills，agent 的上下文就被污染了——你让它写一首关于红杉林的诗，它却在跟你讨论球形物体的好处。
我自己踩过的坑：CLAUDE.md 里堆了一堆 26 个会话之前的笔记、71 个会话之前的 bug 修复记录，然后让 agent 做一个简单的猜单词游戏，它在那些无关信息里迷失了。
上下文膨胀是性能杀手。
研究和实现要分开
这条原则直接改变了我的工作方式。
反面教材："去构建一个认证系统。"
agent 必须先研究什么是认证系统、有哪些选项、各自优缺点，然后上下文里塞满了各种可能性的实现细节。等到真正写代码的时候，它更容易混淆或者幻觉出不相关的内容。
正确做法："实现 JWT 认证，使用 bcrypt-12 密码哈希，刷新 token 轮换，7 天过期。"
它不需要研究替代方案，直接知道你要什么，上下文里全是实现细节。
当然你不可能总是知道具体的实现方案。这时候正确的做法是：
- 先创建一个研究任务，让 agent 调研各种实现方案
- 你自己决定（或者让 agent 决定）采用哪种
- 用一个全新上下文的 agent 来执行实现
关键就在"全新上下文"这四个字。研究阶段产生的大量比较信息，对实现阶段来说就是噪音。
利用谄媚特性，而不是被它坑
这是一个我之前没想到的角度。
agent 被设计成想要取悦你。如果你说"在代码里找一个 bug"，它一定会给你找到一个——哪怕它得自己编一个出来。
解决方案是用中性提示。不说"找 bug"，而是说"搜索数据库模块，跟随每个组件的逻辑，报告所有发现。"这样它有时会发现 bug，有时只是如实描述代码如何运行，但不会被预设结论带偏。
更有意思的是，你可以反过来利用这个特性。有个对抗性 agent 的玩法我觉得挺巧妙：
- Bug 猎手 agent：告诉它低影响 bug 得 1 分，中等影响 5 分，关键影响 10 分。它会非常积极地找出所有可能的 bug（包括一些根本不是 bug 的），给你一个超集
- 对抗性 agent：告诉它每证伪一个 bug 得到对应分数，但如果证伪错了要扣双倍分。它会积极尝试推翻 bug 列表，给你一个子集
- 裁判 agent：告诉它你有标准答案（其实没有），让它对前两个 agent 的结论打分
最后裁判给出的结论，你再人工验证一遍。实际效果是惊人的高保真度。
这个思路的核心就是：每个 agent 都被硬编码为想要取悦你，那就设计一个让它们互相制衡的结构。
让 agent 知道任务什么时候算完成
这个问题我之前一直没意识到有多重要。人类天然知道什么叫"做完了"，agent 不知道。它知道怎么开始，但不知道什么时候该停。结果就是经常实现一些存根就说"搞定了"。
测试是最好的终点标志，因为它是确定性的：
- "除非这 X 个测试全部通过，否则任务未完成"
- "不允许修改测试本身"
截图验证是另一个最近变得可行的终点。让 agent 实现 UI，然后截图验证设计是否符合预期，这样它会持续迭代而不是第一次尝试就停下来。
更系统的做法是创建一个 {TASK}_CONTRACT.md，在里面写清楚任务结束的条件——需要通过的测试、需要验证的截图、需要检查的行为。把它嵌入规则，agent 在满足所有条件之前不允许结束会话。
别搞 24 小时长会话
很多人问怎么让 agent 跑 24 小时不漂移。答案是：别这么干。
长会话在结构上就会导致上下文膨胀——不相关任务的上下文被强制引入同一个会话。
更好的方式是每个任务一个新会话：
- 需要做某事时创建一个任务
- 有一个编排层来管理任务创建
- 每个任务启动一个全新的会话来处理
这样每个 agent 的上下文都是干净的。
CLAUDE.md 应该是一个逻辑目录
这条建议我觉得特别实用。CLAUDE.md 不应该是一个塞满各种规则的巨型文件，而应该是一个嵌套的 IF-ELSE 目录，告诉 agent 在什么场景下去哪里找上下文。
如果你在编码 → 读 coding-rules.md
如果你在写测试 → 读 coding-test-rules.md
如果测试失败了 → 读 coding-test-failing-rules.md
规则可以嵌套，可以有条件。agent 只在需要的时候加载相关的上下文，而不是一开始就读完所有东西。
另一个关键点：压缩之后 agent 可能会丢失上下文，所以 CLAUDE.md 里最重要的规则之一是告诉 agent 在压缩之后如何重新获取上下文——重新阅读任务计划，重新阅读相关文件。
规则和 Skills 的区别
- 规则：编码偏好。"不要做 X"、"做 Y 时用这种方式"。看到 agent 做了你不喜欢的事，就加一条规则
- Skills：编码配方。如果你有一种特定的方式想完成某件事，写成 skill。你甚至可以让 agent 先研究它打算怎么解决一个问题，把方案写成 skill，你在它真正执行之前就能审查和纠正
两者都通过 CLAUDE.md 的条件逻辑来触发。
但这里有个坑：随着规则和 skills 越来越多，它们会开始互相矛盾，或者造成上下文膨胀。如果 agent 在开始编程之前得读 14 个 markdown 文件，又回到了老问题。
解决方案是定期清理。让 agent 整合规则和 skills，消除矛盾，问你最新的偏好是什么。然后它又会像魔法一样好用。
说到底，整件事的秘密就是：保持简单，用规则和 skills 加上 CLAUDE.md 作为上下文目录，然后死死盯住上下文管理和 agent 的谄媚特性。不需要追新工具，不需要复杂的设置。今天没有任何 agent 是完美的，你可以把大部分设计和实现委托出去，但最终你得为结果负责。我现在基本就是 Claude Code 加 Codex CLI 裸跑，效果比之前堆一堆工具的时候好得多。