看了很多论文，写了很多 Demo，做了几个项目之后我才发现：Agent 最难的地方，不是让模型变聪明，而是让人想清楚自己到底想要什么。
一、一个普遍的错觉
最近，Agent 火得一塌糊涂。
ReAct、LangGraph、OpenClaw、Harness Engineering……新概念、新框架、新协议层出不穷。每个听起来都很厉害，每个都宣称能让 Agent 更强大、更通用、更易用。
于是很多人，包括我，产生了一种错觉：
只要我选对了框架、调好了 prompt、接好了工具，Agent 就能帮我解决实际问题。
但真动手做的时候，现实很快就泼冷水：
- 模型确实能调用工具了，但不知道什么时候该用，什么时候该停。
- 加了一个又一个能力，系统反而越来越脆弱。
- Prompt 调了几十版，换个问法又崩了。
- Demo 的时候很惊艳，上线之后用户问三句就露馅。
问题出在哪？
我们太迷信技术了，以为工程难点在代码。但真正卡住大多数人的，是需求还没收敛——大家一头扎进实现，却跳过了最核心的那一步："这个 Agent 到底要解决什么具体问题？"
二、论文和框架不会替你定义问题
这不是批评论文和框架，它们本来就不是干这个的。
论文的任务是证明可能性。
ReAct 论文展示了 Thought-Action-Observation 循环的有效性；SWE-agent 证明了 Agent 可以修代码；各种基准测试证明 Agent 在某些任务上能超过人类。
但论文里的任务，都是已经被定义好的。HotpotQA 有标准问题，ALFWorld 有固定环境，SWE-bench 有明确仓库和 issue。论文不需要回答"这个问题从哪来"，它只需要回答"给定这个问题，我能不能解"。
框架的任务是降低实现成本。
LangGraph 帮你画状态图，AutoGen 帮你搭多 Agent 对话，MCP 帮你标准化工具接口。这些都很重要，但它们都默认一件事：
你已经知道 Agent 该做什么、能做什么、边界在哪里。
如果你连这一步都没想明白，框架只会让问题更加复杂。
三、真正难的是需求收敛
我做了一个叫 minimal-agent 的小项目，初衷是练习 ReAct 范式。
一开始很顺利：写循环、接工具、调 prompt，很快就能跑出一个能查天气、做计算、搜网页的 Demo。
但做到后面，我开始陷入一种熟悉的困境：
- 这个 Agent 到底要解决什么问题？
- 用户会问什么样的问题？
- 哪些能力必须保留，哪些只是"看起来有用"？
- 模型选错工具时，是我 prompt 写得不好，还是这个动作空间本身就有歧义？
我反复修改代码，却始终感觉在原地打转。后来我才意识到：
我不是在解决技术问题，我是在逃避一个更难的问题——把模糊的现实需求，翻译成一个可执行的系统。
这件事没有标准答案，也不能靠堆技术解决。它需要你理解用户、理解场景、理解任务边界。
四、为什么这个问题被严重低估
需求收敛之所以难，是因为它不符合我们对"技术进步"的想象。
我们习惯了这样一种叙事：技术越先进，问题越容易解决。GPU 更快了，模型更聪明了，框架更完善了，所以 Agent 应该离我们越来越近。
但 Agent 和其他软件不一样。
一个传统软件，需求清楚了，剩下的就是实现。但 Agent 的"需求清楚"本身就很难：
- 用户通常说不清楚自己要什么。
- 即使说清楚了，真实场景也比描述复杂十倍。
- 环境是动态的，工具可能失败，模型可能产生幻觉。
- 你以为的"完成"，和用户认为的"完成"，往往不是一回事。
所以 Agent 工程化，本质上不是"让模型执行命令"，而是"让模型在不确定性中，依然做出符合人类预期的行为"。
这需要的不只是技术，还有对问题本身的深刻洞察。
五、POC 和 Demo 掩盖了这个问题
很多 Agent 项目都经历过相似的轨迹：
- 炫酷的 Demo 拿到关注和资源，大家觉得"核心问题已解决，只剩工程化"。
- 真正落地时发现：动作空间、异常处理、用户意图理解全是空白。
- 团队在 prompt、框架、模型之间反复横跳，试图用技术填补需求的缺口。
最危险的是第三步——它制造了一种"我们在快速迭代"的幻觉。实际上，你可能只是在用更复杂的代码，掩盖一个从一开始就没人想清楚的问题。
六、我的尝试：先锁死场景
那该怎么办？
说实话，我现在也没有找到银弹。但我开始尝试一个更收敛的思路：不要先追求通用，先在一个具体场景里把事做扎实。
我拿 minimal-agent 做实验，做了四件事：
第一，砍掉"以后可能用得上"的工具。 从七八个砍到三个（天气、计算、搜索），限定场景为"回答需要外部信息的事实性问题"。动作空间一小，模型的决策质量立刻上来了——选错工具的频率明显下降。
第二，给每个工具写"人话版"说明书。 不是写 search(query: str) 就完事，而是写清楚"什么时候用、参数怎么填"。
第三，准备一组固定测试问题。 20 个问题覆盖单工具调用、多工具组合、模糊意图等场景。每次改 prompt 都跑一遍，看成功率和步数，不再凭感觉判断好坏。
第四，接受"还是有很多问题解决不了"。 比如用户问"帮我规划一下周末"，Agent 就懵了。这时不是加工具，而是做决策：这个场景我要不要做？要做就得重新定义动作空间，不做就明确告诉用户边界在哪。
最大的体会是：
收敛不是限制，而是让问题先变得可解决。
七、写在最后
Agent 工程化落地的距离，可能比我们想象的要远。
这个距离不是从 GPT-4 到 GPT-5.5 的距离，而是从"我们有一个很厉害的技术"到"我们知道怎么用它解决一个具体问题"的距离。论文和框架让我们看到了可能性，但最后一公里没人替你走——它需要你坐下来，认真想清楚用户要什么、场景边界在哪、怎样才算"做完了"。
这件事没有捷径，但它是值得的。
你是怎么看的？你在 Agent 落地时，卡在代码更多，还是卡在问题定义更多？欢迎在评论区讨论。
