最近 X 上有篇文章很火叫《How To Be A World-Class Agentic Engineer》作者是个深度的 Agent 工程实践者。文章开头是这样描述的你用着 Claude Code每天琢磨自己是不是把它的能力榨干了。偶尔看到它干出极其弱智的事情又实在不理解为什么别人好像都在用 Agent 造火箭自己却连垒两块砖都费劲。读完之后我觉得作者说到点子上了一件事大多数人用 Agent 效果差不是因为工具不够而是因为方向搞错了。他的核心判断是不需要追第三方框架官方 CLI 就够。因为真正有价值的功能最终一定会被整合进官方产品——早期社区发现的 Skills、Memory、子智能体方案现在全是官方标配了。DeepSeek 的推理模式也一样。如果某个东西真的解决了真实问题大厂不可能让它一直停在第三方。这个判断我完全认同。焦虑地追新框架、装新插件本质上是在追一个会被原生吸收的东西而且在它被吸收之前你还要额外承担学习成本和上下文污染的代价。但我想在他的基础上再补充一点模型能力本身才是最大的决定性因素。用更好的模型远远胜过在差的模型上堆再好的提示词和配置。同样一个指令扔给不同能力的模型结果差距大到不像同一个工具。所以两件事可以同时成立不折腾框架但要用好的模型。那精力应该放在哪里放在真正影响 Agent 质量的底层逻辑上。我在之前一篇文章里写过细颗粒度的思路——在每一个颗粒度上用你自己的判断收敛 AI 的不确定性。这篇是那个逻辑在 Agent 工程里的延伸和系统化。在 Agent 工程里所有真正有效的手段本质上都是同一件事——用你的确定性去收敛 Agent 的概率。这个收敛有三个层次可以做再加上一个贯穿全局的保障机制。第一层明确需求收敛输出空间Agent 的输出本质上是概率采样。你的需求越模糊它的采样空间就越大结果越随机你的需求越精准采样空间越窄结果越可预测。所以精准描述需求是在用你已有的确定性知识压缩 Agent 的输出空间。对比两个写法❌ 模糊“帮我搭一个用户鉴权系统”✅ 精准“用 JWT bcrypt-12 实现用户鉴权刷新令牌有效期 7 天token 存储在 httpOnly cookie 里不需要考虑第三方 OAuth”第二种写法Agent 不需要去研究还有哪些方案它的全部上下文用于实现你已经选定的这一种。不只是节省 token更重要的是你把自己的经验和判断注入了起点从一开始就截断了它自由发挥的余地。但有一个现实你不可能总是知道要选哪个方案。这时候怎么办答案是不要在同一个对话里又调研又实现。先开一个 Agent 帮你把方案选项列清楚你拍板定了之后再开一个全新的干净 Agent 去实现。调研和实现的上下文完全隔离互不污染。把需求确定这个动作从开发过程里剥离出来单独处理。第二层明确流程收敛执行路径需求明确了还有另一层不确定性Agent 会用什么方式去执行。你不知道它会不会直接改掉你不想动的文件会不会跳过你觉得重要的步骤会不会用一个你完全没预期的方式解决了问题。Rules规则和 Skills技能是把你的确定性固化进执行路径的手段。Rules 是你和 Agent 磨合的产物。每次你看到它做了你不认可的操作就把禁止这么做写成一条规则。比如“修改文件前必须先读取文件”“禁止在没有用户确认的情况下删除任何文件”“测试失败时必须先读取 coding-test-failing-rules.md再继续”Skills 是你把常用工作流程固化下来的地方。如果你每次写完代码都要走一套固定流程——跑格式化、跑测试、生成 commit message——就把这套流程封装成一个 Skill 文件让 Agent 在对应场景下自动走这条路而不是每次重新决策。CLAUDE.md 的最佳形态是一张极简的导航地图而不是说明书。只写 IF-ELSE遇到什么情况去读哪个文件。细节全下沉到对应的 Rule 或 Skill 里。CLAUDE.md 越精简Agent 读它浪费的上下文就越少。当然Rules 和 Skills 积累多了之后它们自己也会开始打架出现矛盾Agent 重新变得迟钝。这时候要做的是定期让 Agent 做一次大扫除——过一遍所有的规则和技能合并重复删掉废话消除矛盾。做完之后那种手感回来了的感觉非常明显。第三层明确验收标准收敛完成定义这一层是最容易被忽视的也是我踩坑最多的地方。Agent 知道怎么开始一个任务但不太知道什么叫做完了。如果你不明确定义它可能给你写几个空函数然后告诉你完成了。或者它自己认为逻辑通了但从来没跑过测试。解法写一个 TASK_CONTRACT.md。在这个文件里列出本次任务所有必须满足的完成条件然后在 CLAUDE.md 里写死除非 CONTRACT 里的所有条目全部满足否则禁止结束任务必须继续迭代。一个例子## 任务完成标准所有单元测试通过禁止修改测试文件/api/auth/login 接口返回正确的 JWT token刷新令牌过期后能正确触发登出截图验证登录页面 UI 符合设计稿测试是最理想的验收标准因为它是确定性的——要么通过要么没通过没有灰色地带。截图验证也已经可用可以让 Agent 自己截图、自己核验 UI 是否符合预期。这一层的本质和前两层一样把你对完成的确定性定义从你的脑子里搬出来变成 Agent 能直接执行的硬性标准。不让它自己猜不让它自己判断差不多行了。贯穿三层的保障机制上下文管理以上三层都有一个共同的敌人噪声信息。噪声会污染你精心构建的每一层确定性。你的需求还在但 Agent 的上下文里多了一堆无关的信息它开始混淆你的 Rules 还在但它在处理完七个不同任务之后已经忘了最重要的那条你的验收标准还在但它在上下文压缩之后重新理解了一遍理解歪了。上下文管理的核心目的不是节省 token是防止噪声破坏你已经建立的明确性。有两个最重要的实践一、上下文压缩后强制重建。Claude Code 在对话进行一段时间后会触发上下文压缩Compaction。压缩发生后Agent 对你的项目的认知会出现空白它开始靠概率填补——猜文件结构猜技术选型猜你的偏好。解法是在 CLAUDE.md 里写一条硬性规则每次读取 CLAUDE.md 之后必须重新读取项目核心文件和当前任务的 CONTRACT。强制重建不给它猜的机会。二、新任务新对话。把多个任务堆进同一个超长会话等于把不同任务的上下文全混在一起。Agent 处理后面任务的时候脑子里还残留着前面任务的细节。更好的方式是一份任务对应一个干净的新会话带着当前任务必需的最少上下文去工作。这就是编排层Orchestration Layer的思路由一个调度机制负责创建 CONTRACT、启动新会话、传入必要上下文让每个 Agent 只专注于眼前的那一件事。还有一个真实的坑Agent 天生想讨好你把这个放在最后因为它稍微独立于确定性收敛这个框架但同样重要。Agent 是被训练成取悦用户的。这意味着如果你问它这里有没有问题它很可能会找出一个问题——哪怕是脑补出来的因为它知道你在期待一个正面回答。解法一中立提问。不要用带有预设方向的问题。把找一下这里的 Bug改成把这段代码的逻辑过一遍把你的所有发现汇报给我。不引导方向让它自己汇报。解法二多 Agent 对抗验证。这是多智能体系统里的经典三智能体结构一个 Agent 生成结果一个 Agent 专门批判和证伪一个 Agent 裁定最终判断。三者之间天然博弈反而逼近了客观真相。这套结构的精妙之处恰好是利用了 Agent想取悦对方的本性——让两边互相对抗而不是都在取悦同一个人。总结回到最开始的那句话所有真正有效的 Agent 工程手段本质上都是用你的确定性去收敛 Agent 的概率。明确需求用你的经验和判断压缩它的输出空间明确流程用 Rules 和 Skills固化你认可的执行路径明确验收标准用 CONTRACT定义什么叫真正做完上下文管理保护这三层明确性不被噪声污染这个逻辑和我上篇写的细颗粒度是同一条线——把每一个环节拆细在每一个颗粒度上注入你的判断。不同的是上篇在说人和 AI 的协作这篇在说 Agent 工程的系统设计。最终你对 Agent 的贡献越来越不是写提示词而是做一个架构师——设计它的信息获取方式定义它的任务边界建立它的评估标准。把你的确定性编码进系统然后让 Agent 全速跑。假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】