为什么同样的 Coding Agent，有人觉得神，有人觉得废？

这段时间我越来越强烈地感受到一件事：

同样是 Coding Agent，有人已经把它用成了真实搭档；也有人用了几次之后，最后只剩下一句：不行，还是不靠谱。

更有意思的是，很多时候大家用的还是同一批工具、同一代模型。既然底层能力没有差到像换了一个物种，为什么最后体验会差这么大？

我现在越来越倾向于一个判断：

Coding Agent 的体验差异，越来越不是模型差异，而是上下文工程差异。

真正拉开差距的，不只是模型够不够强，而是你有没有把任务讲清楚、把项目信息喂完整、把中间检查点设计好，以及有没有用“协作”的方式，而不是“外包”的方式去使用它。

同一个 Agent，为什么会像两个产品？

如果你最近经常看 AI Coding 相关讨论，会发现一个很有意思的现象。

一边是极度兴奋的人：

“已经可以做复杂重构了”
“多文件修改完全能干”
“现在真的像带了个能干活的搭档”

另一边则是完全失望的人：

“除了写 demo 没啥用”
“一复杂就乱”
“看起来很聪明，做起来全是坑”

以前我会把这种分歧理解成“有人激进，有人保守”。但现在我越来越觉得，不是这么简单。

因为在很多场景里，大家用的并不是完全不同的工具，很多时候都在用 Claude Code、Codex、Cursor，或者同一代模型能力。既然底层并没有拉开一个数量级，那最后体验为什么会差得这么夸张？

我的答案是：

很多人以为自己在比较模型，实际上比较的是一整套上下文条件。

也就是说，一个 Coding Agent 好不好用，从来都不只取决于它“会不会写代码”，还取决于它是在什么前提下、以什么方式、拿着什么上下文去写代码。

同一个 Agent，放在两个人手里，之所以像两个产品，不一定是因为 Agent 变了，而是因为：

一个人给它的是清晰任务、完整上下文、明确约束
另一个人给它的是模糊目标、脏乱仓库、全自动幻想

你喂给它的工作环境不一样，它表现出来的能力上限，当然也不一样。

真正拉开差距的，是上下文工程

“上下文工程”这个词现在经常被提到，但很多人理解得还是太窄了。

一提上下文，很多人想到的是：“哦，就是 prompt 写得好一点。”

这当然算，但远远不够。对 Coding Agent 来说，上下文不是一句提示词，而是一整套让它能稳定干活的工作环境。

我更愿意把它拆成四层。

第一层：任务上下文

最基础的一层，是任务本身有没有被说清楚。

比如你让它：

“帮我优化一下这个项目”
“把这个模块重构一下”
“修一修这个功能”

看起来像在提需求，实际上几乎没给边界。

什么叫优化？优化性能、结构还是命名？什么叫重构？是保留行为不变，还是允许改接口？什么叫修一修？是先修 bug，还是顺手补测试？

人类工程师遇到这种需求，都会先追问。但很多人对 Agent 的期待却是：你自己懂。

问题就在这里。Agent 不是不会写，而是它会在不够明确的目标下，擅自补完一个“它以为你想要的任务”。

一旦补完方向偏了，后面就会越来越像在认真推进，但离目标越来越远。

所以一个 Coding Agent 好不好用，第一步不是看模型，而是看你有没有把任务边界讲明白：

目标是什么
不要做什么
成功标准是什么
哪些文件可以改
哪些行为不能变

很多人抱怨 Agent 不稳定，根子不是它输出随机，而是输入本来就含糊。

第二层：项目上下文

再往上一层，是项目上下文。

这才是 Coding Agent 真正开始分层的地方。因为它不是在做一道算法题，而是在接手一个真实的代码仓库。

而真实代码仓库里，决定它能不能干活的，往往不是代码本身，而是代码之外的那些东西：

README 有没有写清楚
目录结构有没有说明
架构分层是不是能看懂
哪些模块是历史包袱
哪些约定不能碰
哪些文件虽然能改，但最好别改

这些信息，对人类工程师来说，通常是靠长期协作和历史经验慢慢补上的。但 Agent 没有这个背景。

它能读代码，不代表它能读出“这段代码为什么长成这样”。它能遍历仓库，不代表它知道“这个目录虽然丑，但背后是线上兼容约束”。

所以很多时候，决定 Agent 质量的，不是模型会不会写，而是：

你有没有把项目里那些隐性知识，提前显式化。

这也是为什么我越来越觉得，像 AGENTS.md、README、目录约定、模块说明这种文件，未来会变得越来越重要。

它们以前主要是写给人看的，以后会越来越像写给 Agent 的“项目操作手册”。

第三层：流程上下文

再往上一层，是流程上下文。

很多人现在用 Agent 的默认方式是：

把任务一次性丢过去
等它自己跑完
出问题再骂它不靠谱

但真实工程工作不是这么跑的。

靠谱的流程通常是：

先确认理解
再拆步骤
中途检查方向
小步提交
每一步都能验证

如果你的使用方式是“整包外包给 Agent”，那它失败的概率本来就会急剧上升。

所以真正稳的做法，不是让 Agent 一口气包办，而是把它放进一条可检查、可回退、可验证的流程里。

说白了，Agent 不是不能承担复杂任务，而是复杂任务必须有中间控制点。

第四层：协作上下文

最后一层，是协作上下文。

这也是我越来越在意的一点：

很多人嘴上说在用 Agent，实际心态还是在找一个“更便宜的外包”。

这会直接带偏使用方式。

如果你把 Agent 当成外包，你会天然期待：

我提一句，你全做完
我不解释，你自己懂
我不检查，你别出错

但如果你把它当成协作对象，使用方式就完全不一样了。

你会主动提供背景、补足约束、做中间确认、控制节奏。这样它的表现通常会稳定很多。

所以我越来越觉得，Coding Agent 的上限，不只是“模型能力上限”，更是“协作系统上限”。

为什么很多人会误判 Agent 的能力？

因为他们经常把上下文问题，误判成模型问题。

比如：

任务没说清楚，最后怪模型理解差
项目约束没讲，最后怪模型乱改
流程没设检查点，最后怪模型不稳定
期待全自动交付，最后怪模型不靠谱

这些当然不能说跟模型完全无关，但如果你把锅全甩给模型，就很容易得出错误结论。

我现在越来越相信一句话：

很多 Agent 的失败案例，并不是“模型不会”，而是“系统没喂好”。

这也是为什么同样的工具，在不同团队、不同个人手里，口碑会像坐过山车一样分裂。

以后真正值钱的，不只是会用 Agent，而是会做上下文工程

如果这个判断成立，那接下来真正值钱的能力就不只是“会不会写 prompt”，而是：

会不会定义任务边界
会不会整理项目上下文
会不会设计协作流程
会不会把隐性知识显式化
会不会把 Agent 接进一个可验证的工作系统

这也是我最近越来越在意的一点：

未来真正拉开差距的，可能不是谁先用上了 Agent，而是谁先学会了给 Agent 搭工作环境。

模型会越来越强，工具会越来越像，长上下文、工具调用、代码编辑、多文件修改，这些能力迟早都会逐步趋同。

但上下文工程不会自动趋同。因为它更像组织能力、工程能力和使用方式的综合体现。