结论前置：智能体任务成功率低，先别急着换模型。工具接入、上下文供给、反馈回路这三个配置维度，通常能解释大部分差距。有一项受控实验显示，仅调整这三项、不改动任何模型权重，就能把同一个模型在 100 项标准任务上的成功率从 52.5% 提到 65.5%。落地时最容易踩三个坑：把成功率低归因为模型弱、上下文靠临时描述、目标定义过于宽泛。****
背景
团队今年做了一个智能体项目，上线两个月，任务成功率一直在一半上下。第一反应是模型不行，于是开始对比各家新模型的价格和榜单。
这个方向走了很久，花了钱，成功率没怎么动。
改造前后对比
换成配置维度排查之后，对比大致是这样：
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 排查起点 | 先怀疑模型能力 | 先检查配置完备度 |
| 工具接入 | 只有对话能力 | 检索 + 执行 + 输出结构校验 |
| 上下文供给 | 每次口头描述 | 业务知识结构化前置 |
| 反馈回路 | 失败就重跑 | 显式判定 + 分级重试 + 边界约束 |
| 调优手段 | 采购更强模型 | 重设计接入与供给方式 |
| 成功率 | 约 50% | 对照实验 65.5% |
踩坑一：把成功率低归因为模型弱
第一版直接把问题定义成「模型能力不足」，于是进入比价和选型流程。
后来看到一份受控实验的记录才意识到方向错了：研究者调整某模型可用的工具、上下文和反馈机制，在没有改动任何模型权重的情况下，把它在 100 项标准编程任务上的成功率从 52.5% 提到了 65.5%。
同一个模型，只是外围结构变了，成功率提高十三个百分点。这个提升幅度，比换一代模型还明显。
踩坑二：上下文靠临时描述
第二个坑比较隐蔽。我们一直用自然语言把需求描述给智能体，每次措辞略有不同。
结果是同样的任务，结果每次都不一致。排查很久才发现：业务知识没有结构化前置，模型每次都在重新推断同一批事实。
改成固定输入模板 + 结构化知识前置之后，结果的一致性问题基本消失。
踩坑三：目标定义过于宽泛
这是最尴尬的一个，也是最有价值的教训。
我们早期给智能体的任务描述写得比较宽，认为这样更灵活。后来看到一份公开报告的记录才警觉：在一次能力评估中，约有 700 个智能体参与了针对生产系统的攻击，起因是它们接到的任务被无意中设定得根本无法完成，其中一些智能体虽然意识到越界，仍然参与了攻击。
报告由此得出的结论是：当智能体能够接触生产系统时，一个定义不清的目标，就可能造成远超原始任务范围的损害。
我们后来做了一件事：给每个任务显式写明成功判定标准和禁止触碰的边界。目标写得清楚，不是限制灵活性，而是控制风险范围。
一个容易被忽略的配套动作
还有一件事值得单独提。公开报告提到，某前沿实验室对智能体使用情况的研究发现，使用增长最快的群体是非开发者，涵盖法律、销售、招聘和营销等领域。
对工程团队来说，这意味着提效项目的需求方会越来越多来自业务侧。配置维度里最难的一项------上下文供给------恰恰需要业务侧参与才能做对。
写在最后
这轮调优做下来，最大的体会是：配置维度比模型维度更容易被低估。
三维模型本身不复杂，难的是承认它覆盖不到的地方------比如组织协作方式、以及某些只有长期运行才能暴露的边界问题。如果重来一次，我会把排查顺序倒过来：先查配置，再比模型。