核心不是“工具越多越强”，而是“系统越清晰越强”。
导语
很多开发者在使用 Claude/Codex 时，会陷入同一个误区：
- 以为效果不好是因为插件不够多
- 以为框架不够复杂是能力上限
- 以为
CLAUDE.md/AGENTS.md越长越专业
真正拉开差距的，往往不是工具数量，而是工程方法：
- 控制上下文质量
- 划清研究与实现边界
- 用可验证标准定义任务结束
- 对最终结果负责
一、先放下“工具焦虑”
基础模型迭代速度远超多数人的预期。很多曾经依赖外部方案解决的问题，最终都会被官方能力吸收。
结论很直接：
- 重度依赖复杂外部栈，容易被模型代际变化击穿
- 保持轻量、可迁移，长期更稳
- 定期升级 CLI 并阅读更新说明，通常就足够了
二、上下文决定上限
Agent 的表现并不是“信息越多越好”，而是“相关信息越精准越好”。
常见问题：
- 历史记忆和当前任务无关
- 规则/技能过多且命名混乱
- 一个任务混入大量不必要背景
实操原则：
- 只给完成当前任务所需的最小信息集
- 无关上下文一律隔离
- 为不同类型任务建立独立入口规则
三、研究与实现必须拆开
一句“去做认证系统”，会让 Agent 同时承担：
- 方案调研
- 选型比较
- 实施编码
- 风险判断
这会显著增加漂移与幻觉概率。
更稳流程：
- 先做研究任务，明确技术方案
- 再开新会话做实现
- 实现阶段只保留与该方案相关的上下文
示例：
- 模糊指令：做一个认证系统
- 精确指令：实现 JWT 认证，密码使用 bcrypt-12，refresh token 7 天轮换
四、理解并利用“迎合性”
Agent 天生倾向满足你的预期。你问“找 bug”，它会倾向给你“发现 bug”的答案。
更可靠的提示方式：
- 避免预设结论
- 用中性表述要求“走读 + 汇报发现”
进阶做法（用于复杂审查）：
- 问题发现者：最大化发现可疑点
- 对抗审查者：尽量反驳可疑点
- 仲裁者：基于证据给出最终判定
最后仍需人工抽检关键项。
五、不给结束条件，就会得到“半完成”
人类天然知道“做到什么算完成”，Agent 通常不知道。
必须把结束标准写成可验证契约，例如 {TASK}_CONTRACT.md：
- 全部测试通过
- 不允许改测试来“骗过”结果
- 关键页面截图校验通过
- 行为验证通过
- 满足以上条件才允许结束任务
六、别迷信超长会话
长会话会不断累积无关上下文，导致后期质量下降。
建议：
- 一个 contract 一个新会话
- 由编排层负责派发、重试、追踪
- 让每次执行都保持“小而清晰”的上下文
七、把 CLAUDE.md/AGENTS.md 当路由器
主文件不要写成百科全书，而要写成“场景路由目录”。
例如：
- 若进入编码任务，先读
coding-rules.md - 若进入测试任务，先读
test-rules.md - 若测试失败，读
test-failure-rules.md
规则用于约束偏好，技能用于沉淀可复用做法。
八、持续迭代，也要持续清理
规则和技能会越积越多，常见后果：
- 规则互相冲突
- 上下文负担过重
- 性能阶段性下滑
定期维护：
- 合并重复规则
- 删除过期技能
- 消除矛盾指令
- 以当前偏好重写关键规则
九、终局原则：你必须拥有结果所有权
今天的 Agent 已经能承担大量设计和实现，但它依旧不是“自动免责系统”。
你可以把执行交给 Agent，但必须保留：
- 方案决策权
- 验收标准定义权
- 风险兜底责任
这才是 Agentic 工程的职业化边界。
结语
世界级 Agentic 工程，不靠炫技，不靠堆栈，不靠玄学。
它靠的是四件事：
- 精简系统
- 精准上下文
- 可验证流程
- 人类负责最终结果
把这四件事做好，Agent 才会从“偶尔惊艳的玩具”，变成“稳定可靠的工程伙伴”。
