当所有Agent都在卷执行，Spice想去管「决策」
2026年的Agent赛道，已经卷到没人再讨论「能不能干活」这件事了。Cursor、Claude Code、Manus、通义灵码2.0，一众产品把执行层做到了几乎能替代初级工程师的程度。但一个被刻意回避的问题是——这些Agent干完活，你能说清它为什么这样干吗？
5月15日，开发者 Jia 把开源Agent框架 Spice 推到了一个新版本。距离它首次亮相过去一个多月，这次更新瞄准的是一个相当不讨好的方向：让Agent的决策过程从黑盒里走出来。
这不是又一个 ReAct 套壳，也不是 LangGraph 风格的编排器。Jia 在 LINUX DO 社区的更新帖里把话说得很直接：现在市面上绝大多数 Agent，本质上还是「人类决定做什么，Agent 决定怎么做」的工具代理。Spice 想往前再走半步。
执行层Agent的天花板，比想象中来得早
要理解 Spice 的切入点，得先看清楚现在 Agent 圈的几个共识性瓶颈。
第一个是决策黑盒。 不管你用 ReAct、Reflexion 还是 RL 训出来的 harness，Agent 在 loop 里调用某个 tool 的真实原因，对外几乎不可见。你看到的是 thought→action→observation 的文本流，但模型为什么在第三步突然决定调 search 而不是 read_file，没人讲得清。这导致目前所有 Agent benchmark 都只能从 result 反推能力——SWE-Bench 跑通几道题、WebArena 完成率多少，都是结果指标。过程指标几乎是空白。
第二个是不可审计、不可回溯。 这件事在个人玩具里不重要，在企业里要命。一个跑了40分钟、调了200次工具、最后把生产库表 drop 掉的 Agent，事后你拿什么追责？traces 日志能告诉你它做了什么，但告诉不了你它为什么认为这样做是对的。
第三个是编排层的膨胀。 A2A、MCP、各种 memory 中间件、各种 gateway（比如 Jia 提到的 OpenClaw 那类把 entrance 重做一遍的方案），让 Agent 从一个 chatbot 演化成了一个有点像「数字员工」的东西。《2026年全球智能体白皮书》里那个57%企业部署多阶段Agent的数字，背后其实是一堆缝合起来的 infra。Agent 越多、越能干，对「谁在做决策、按什么逻辑做决策」的可解释性要求就越高。
Spice 的判断是：执行层这条路再卷下去，边际收益会非常低，而决策层几乎是空的。
Spice 想做什么：把决策从模型里「拆」出来
按 Jia 的描述，Spice 的核心设计有几个不太常见的取舍：
- 决策路径显式化：不把规划塞进 system prompt 让模型自己 reason，而是把决策步骤抽成可观测、可干预的 graph 节点。每一次工具选择、每一次分支，都是一条可被外部审计的记录。
- 执行与决策解耦：执行层 Agent（写代码的、查资料的、做RPA的）作为可插拔的 worker，Spice 本身只负责「派谁去、为什么派、派完怎么验证」。这跟通义灵码2.0那种「环境+智能体」的多智能体框架在思路上有点像，但 Spice 更激进——它不假设 worker 是同构的。
- 过程数据可导出：这是为了应对一个现实问题——做 self-evolving Agent 的人都在吐槽缺过程数据。Spice 把决策轨迹做成结构化输出，理论上可以直接喂给后续训练。
这里其实呼应了最近圆桌讨论里反复被提的一个观点：self-evolving 的真正难点不是模型自己刷题，而是缺乏过程数据和能与之共同进化的环境。SPICE 这个名字（Self-Play In Corpus Environments）在学术圈本来就有同名工作，Jia 的这个 Spice 虽然定位不同，但思路上确实站在了同一波浪潮里——Agent 想往上走，决策过程必须被结构化。
一个不太一样的做法：把「为什么」变成一等公民
传统 Agent 框架里，「为什么这么做」是 thought 字段里的一段自然语言，模型自己写给自己看。Spice 的做法是把它升级成框架层的对象——每一次决策都会带上：
- 候选 action 集合
- 选中 action 的判据（可以是规则、可以是模型评分、可以是外部 verifier）
- 当时的上下文快照
- 后续可回滚的 checkpoint
这样做的代价是显而易见的：性能开销、token 消耗、工程复杂度都会上一个台阶。好处是，当一个 Agent 在生产环境里跑出意料之外的结果，你第一次有办法 step-by-step 地复盘，而不是去翻几万行 trace 日志。
对比一下市面上的几个方向：
| 框架 | 重点 | 决策可审计 |
|---|---|---|
| LangGraph | 编排DAG | 部分（节点级） |
| AutoGen | 多Agent对话 | 弱 |
| CrewAI | 角色分工 | 弱 |
| Spice | 决策显式化 | 强（设计目标） |
当然这张表对 Spice 是有点偏心的——它现在还在早期，工程成熟度跟前面几个不在一个量级。但方向上的差异是真实的。
谁会用 Spice
说实话，个人开发者短期不太会迁移。你用 Cursor 写代码，根本不关心它为什么决定先读哪个文件。Spice 这种「重决策」的框架，目标用户更可能是这几类：
- 企业内部跑关键业务流的团队：合规、金融、医疗这类场景，Agent 的每一步都要能解释、能回滚。
- 做 Agent 训练数据的团队：需要高质量的过程轨迹来做 SFT 或 RL。
- 做 Agent 评测的研究者：从 result-based benchmark 转向 process-based benchmark 是迟早的事。
Jia 自己也提到，过去一个月跟投资人和技术圈交流下来，反馈最强烈的也是来自这几类用户。这其实暗示了一件事：Agent 行业可能正在分层，一层是面向终端用户的执行Agent（卷体验、卷速度），另一层是面向企业和研究者的决策基础设施（卷可控性、卷可审计）。Spice 押的是后者。
还需要回答的问题
抛开方向不谈，Spice 现阶段也有几个绕不过去的问题：
- 决策显式化和模型能力的边界：当 base model 越来越聪明（比如 GPT-5、Claude 4.5、Gemini 3 这一代），把决策从模型里硬拆出来，会不会反而降低了 Agent 的整体表现？这是一个经典的「explicit vs. emergent」之争。
- 生态适配：现在的 Agent 生态都是围绕 ReAct/MCP 这套范式建的，Spice 要让自己的决策协议跑通，需要适配大量现有的 tool 和 worker。
- 性能成本：每一步都要记录候选集、判据、checkpoint，token 和延迟都会涨。在企业场景里能不能接受，要看具体业务。
这些问题没有标准答案。但 Spice 至少把一个长期被遮在执行层光环下的问题摆到了台面上：Agent 不是干完活就完事，谁来为它的每一个决定负责，谁来让这些决定可被改进，这件事比再写一个更快的 ReAct 重要得多。
顺带一提，Spice 里跑的底层模型可以接任何 OpenAI 兼容的 endpoint，OpenAI Hub 这种聚合 GPT、Claude、Gemini、DeepSeek 的网关刚好能用上——一个 Key 切换不同 base model 做决策对比，对早期调试 Spice 这类框架还挺顺手的。
参考来源
- Spice 项目介绍与更新帖 - LINUX DO：作者 Jia 关于 Spice 设计理念的第一手说明
- 自进化≠自我刷题，Agent 真正的突破口是「自己造环境」？- 知乎：6位学者关于 Agent 自进化与决策过程数据的圆桌讨论