工具精简，胜过堆叠
很多人掉进了"工具崇拜"的坑：疯狂安装插件、记忆系统、各种 harness，以为这样能让 Agent 更强。实际效果恰恰相反——这些外部依赖带来的是上下文污染，Agent 的表现反而会下降。
近乎裸机的 CLI 配置（Claude Code + Codex），反而能产出最好的工作成果。少即是多，在 Agent 工程中尤其如此。
模型在飞速进化，别为缺陷过度设计
几个版本前，在 CLAUDE.md 里写"先读这个文件"，Agent 有 50% 的概率直接无视。现在，它已经能理解嵌套的条件指令，比如"如果满足条件 C，则去读文件 D"。
这意味着：你今天为某个模型缺陷设计的复杂 workaround，很可能在下个版本就失效，甚至被模型原生实现。保持方案的简洁和可替换性，比精巧的补丁更重要。
上下文管理：最被低估的工程能力
一句话原则：给 Agent 完成任务所需的确切信息，不多也不少。
最关键的一条：研究与实现必须分离。
- 错误做法："帮我构建一个认证系统。"——Agent 会去调研所有方案，上下文被各种备选实现细节填满，真正实现时容易混乱甚至产生幻觉。
- 正确做法："用 bcrypt-12 实现 JWT 认证，refresh token 7 天过期……"——上下文直接聚焦实现细节，干净利落。
如果你自己还不确定该怎么做，流程应该是：
- 开一个 Agent 做调研，输出方案对比
- 你（或让 Agent 辅助）做决策
- 另开一个全新上下文的 Agent 来实现
这一步容易偷懒，但混用调研和实现的上下文，几乎必然导致质量下降。
巧用 Agent 的"奉承性"
Agent 天然倾向于"取悦用户"——你让它找 bug，它就会找到 bug，哪怕需要编造一个。这不是 Agent 的问题，是你的提示词问题。
方案一：中性提示词
别说"找 bug"，改成"梳理各模块的逻辑，报告所有发现"。中性提示不预设结论，Agent 会如实汇报——有 bug 说 bug，没有就说没有。
方案二：多 Agent 对抗机制
设计一个三角验证系统：
- Bug 发现者：发现低/中/高影响 bug 分别得 +1/+5/+10 分
- 对抗者：成功反驳得对应分数，反驳错误扣 2 倍
- 裁判：被告知存在真实答案参照，对错各 ±1 分
通过激励机制让 Agent 之间互相校验，比单个 Agent 自查可靠得多。
给任务定义明确的"终点"
Agent 擅长开始任务，但不知道何时该停——这是当前模型的固有限制。两种可靠的终点定义方式：
- 测试套件：明确告诉 Agent"X 个测试全部通过才算完成，且不得修改测试文件"。测试是确定性的，Agent 无法糊弄。
- 截图 + 视觉验证：让 Agent 实现功能后截图，验证设计或行为是否符合预期，根据截图反复迭代直到满足要求。
更进一步的做法：为每个任务创建 {TASK}_CONTRACT.md，列出所有验收条件（测试通过、截图验证等），结合 stop-hook 机制，强制 Agent 在合同完成前不得退出。
长时间运行 Agent 的正确方式
"24 小时连续运行的超长会话"是个坏主意。多个不相关任务的上下文混在一起，会导致漂移和质量下降。
推荐的做法：
- 每个合约（任务）开一个新会话
- 用一个编排层负责创建合同、分发新会话
- 会话完成即关闭，下个任务开新会话
干净的上下文，才有稳定的输出。
规则与技能的管理体系
CLAUDE.md 的正确定位：不是一份完整文档，而是一个条件跳转目录。它只告诉 Agent 在什么场景下去读哪个文件。
- 如果你在写代码，先读 coding-rules.md
- 如果你在写测试，先读 coding-test-rules.md
- 如果测试失败，先读 coding-test-failing-rules.md
在此基础上，区分两类文件：
- 规则（Rules）：编码偏好——"不要做 X"、"总是做 Y"。每次看到 Agent 做了你不满意的事，就写成规则。
- 技能（Skills）：编码方法——"按照这个流程做 Z"。想让某件事的做法确定可控，先让 Agent 研究怎么做，把方案写成 Skill 文件，你审阅修正。这样在真实场景出现之前，你就已经掌握了 Agent 的解法。
需要注意的是，规则和技能积累到一定程度会出现矛盾和冗余，反而拖累性能。定期让 Agent 整合去重，向你确认最新偏好——这是一个需要周期性执行的维护动作，别指望一劳永逸。
写在最后
Agentic Engineering 的核心不是让 Agent 替你思考，而是你用更精准的方式指挥 Agent 执行。上下文管理、任务边界、规则维护——这些看起来不性感的工作，恰恰是拉开差距的地方。与其追逐更多工具，不如把手头的工具用到极致。