我把 Agent 决策黑盒里的 “why A, not B” 拿出来了
- 内容介绍
- 文章标签
- 相关推荐
最近使用Hermes + Spice有一些感触，我们刚给Spice加了一个小功能，之前从外部很难看清Spice为什么会这么建议，加完这个功能后Spice可以更清楚的展示为什么选A但是不选B。
现在的Agent设计无论是ReAct还是RL这些方法论，决策和执行常常被放在同一个loop里，举个例子来说，你问chatgpt我5点有个会议但我收到了一个work item我该怎么办，他一般会直接回答你建议，比如：你的这个work item重要吗，我建议你先处理工工作。但他是如何产生这次建议的，建议的依据是什么你没法清楚的了解。这些依据往往被藏在模型的上下文和reasoning里，不是一个稳定的对象。
我们这次加了个小的功能就是让你清晰的知道“为什么让你先处理工作”，基于什么原因给了你建议，把这个模糊黑盒里的decision展开成为一个对象。
写在开头
这个更新的起因其实是我和朋友的 Agent 做了一次对话。他质疑我们有了很不错的方向，很好的愿景，但现状是“结构本身不产生智能”。这句话让我重新审视了Spice的现状和目前的价值，我们还不足以证明我们能做出更好的决策，我们现阶段做到的只是个开始，即让 decision 本身变成一个可以被系统观察、比较和追踪的对象。
551220×1268 240 KB
所以这次更新，我们还没有去添加更新的执行能力，更好的UI或是新的benchmark，我们只是补了一层很小但关键的东西：Human-readable Decision Comparison。
更新内容
这次更新的内容很简单，把已有的decision trace，整理成一个人可以读懂的comparison object。他只回答一个问题就是为什么Spice选A不选B？
下面是我们这次更新后的一次测试demo：
这次demo的测试用例很简单，用户眼下有一个立刻要处理的GitHub work item，但离下一个会议commitment只剩一个很短的时间，这时候系统要决定立刻处理，先快速triage再defer，暂时忽略还是委托给可用的executor（这里的executor指的就是外部执行层agent）。
这几张图不是普通的终端输出，他展示的是一个decision object。
在这个comparison object里，Spice把这次decision相关的依据都展开了：
- state
- candidate
- tradeoff
- veto
- constraint
- selected recommendation
- why-not
- trace / id
他不再只是告诉你该怎么做，而是把
为什么这么做，为什么不是别的选择都清晰的展示给你
图12538×1484 414 KB
图一展示的是这次 decision 的起点，重点不在于信息更多，而是哪些状态和条件真的在约束这次选择。
Spice不是直接从context里跳到一句建议，而是先把 decision-relevant state 和 候选action显式展开。有了这一步的支撑才让后面的选择不再像是黑盒里突然跳出来的结论，而是建立在一个可见的comparison object上。
图22530×1140 344 KB
图二是这次更新最关键的部分：为什么选中了这个，为什么没选另外几个。
Spice的输出不再是:
“我建议你…”
而是把 comparison 本身显式化：
- 哪些 candidate 被 veto 了
- 哪些 candidate 可行，但在当前 tradeoff 下没有胜出
- 最后被选中的 candidate，主要依据是什么
这里不是说“把推荐理由写详细了一点”或者“补了一段explanation“，why A, not B 不再是一段解释文本，而是 decision object 里可追踪的结构化字段。。
图31538×168 10.5 KB
上面两张图展示的是Spice把decision从黑盒里拿出来了。
而图三想说的其实是这个 decision object 后面怎么接 execution layer，这个object不止是纸上谈兵，而是已经接入真实executor的完整闭环且它还能跨 execution boundary 进入执行链路。
这也是我为什么一直在不停的解释Spice不是orchestration，不是一个Agent编排架构，Spice只负责decision，Hermes/OpenClaw/CC/Codex等这类executor才负责execution。中间通过SDEP进行通信和链接。
更新总结
这次更新补上的，其实是 Spice 之前缺的一层：不是让 Spice 更会“说”，而是让 Spice 第一次把 decision 拿到了台面上，他还没有解决所有决策问题，但至少先把“为什么选 A 不选 B”变成了一个系统里可以被观察、比较、追踪的对象。只有让decision先显式的成为系统对象，后面才有可能做好decision evolution。
写在最后
无论是和佬友们的交流还是和空系的思想碰撞，都让我看Spice看的更清晰更具体。
Spice的愿景依然没变：
感知万物，做最适合你的决策，你的“AI大脑”
还是想做 decision layer above agents，还是想把决策和执行分开 evolution。
当前最重要的把“decision 到底是什么”先做成一个能被系统操作的对象”这一步我们已经补上了。
后面我们还会继续补：
- 更强的 simulation / consequence modeling
- 更真实的 decision feedback loop
- 以及更强有力证明决策更好的benchmark
我们要从让decision可以被系统操作这一步开始，迈向真正的让decision可以持续的进化，变得更好。
感谢佬友们的支持和鼓励，欢迎大家持续 网友解答：
--【壹】--：
重新编辑了一下，前面写的不是很好，期待和L友们交流！
--【贰】--：
更多spice相关可以看我第一篇帖子或者去看GitHub，有任何不懂或者问题都可以直接问我呀[开源] 执行层agent爆发引发思考，于是我做了Spice（小辣椒）这个开源项目... - #91，来自 Jiaa
--【叁】--：
没看懂，有点点收获，但不妨碍我想说大佬 666
--【肆】--：
更多Spice的相关内容可以去看我的第一篇帖子！[开源] 执行层agent爆发引发思考，于是我做了Spice（小辣椒）这个开源项目... - #91，来自 Jiaa
--【伍】--：
我的帖子没有任何AI润色或AI生成，全部是我自己手写各位佬友…
GitHub：GitHub - Dyalwayshappy/Spice: percept everything and make the 'best' decision for you. Your second 'brain' 感知万物，做最适合你的决策，你的“第二大脑” · GitHub
最近使用Hermes + Spice有一些感触，我们刚给Spice加了一个小功能，之前从外部很难看清Spice为什么会这么建议，加完这个功能后Spice可以更清楚的展示为什么选A但是不选B。
现在的Agent设计无论是ReAct还是RL这些方法论，决策和执行常常被放在同一个loop里，举个例子来说，你问chatgpt我5点有个会议但我收到了一个work item我该怎么办，他一般会直接回答你建议，比如：你的这个work item重要吗，我建议你先处理工工作。但他是如何产生这次建议的，建议的依据是什么你没法清楚的了解。这些依据往往被藏在模型的上下文和reasoning里，不是一个稳定的对象。
我们这次加了个小的功能就是让你清晰的知道“为什么让你先处理工作”，基于什么原因给了你建议，把这个模糊黑盒里的decision展开成为一个对象。
写在开头
这个更新的起因其实是我和朋友的 Agent 做了一次对话。他质疑我们有了很不错的方向，很好的愿景，但现状是“结构本身不产生智能”。这句话让我重新审视了Spice的现状和目前的价值，我们还不足以证明我们能做出更好的决策，我们现阶段做到的只是个开始，即让 decision 本身变成一个可以被系统观察、比较和追踪的对象。
551220×1268 240 KB
所以这次更新，我们还没有去添加更新的执行能力，更好的UI或是新的benchmark，我们只是补了一层很小但关键的东西：Human-readable Decision Comparison。
更新内容
这次更新的内容很简单，把已有的decision trace，整理成一个人可以读懂的comparison object。他只回答一个问题就是为什么Spice选A不选B？
下面是我们这次更新后的一次测试demo：
这次demo的测试用例很简单，用户眼下有一个立刻要处理的GitHub work item，但离下一个会议commitment只剩一个很短的时间，这时候系统要决定立刻处理，先快速triage再defer，暂时忽略还是委托给可用的executor（这里的executor指的就是外部执行层agent）。
这几张图不是普通的终端输出，他展示的是一个decision object。
在这个comparison object里，Spice把这次decision相关的依据都展开了：
- state
- candidate
- tradeoff
- veto
- constraint
- selected recommendation
- why-not
- trace / id
他不再只是告诉你该怎么做，而是把
为什么这么做，为什么不是别的选择都清晰的展示给你
图12538×1484 414 KB
图一展示的是这次 decision 的起点，重点不在于信息更多，而是哪些状态和条件真的在约束这次选择。
Spice不是直接从context里跳到一句建议，而是先把 decision-relevant state 和 候选action显式展开。有了这一步的支撑才让后面的选择不再像是黑盒里突然跳出来的结论，而是建立在一个可见的comparison object上。
图22530×1140 344 KB
图二是这次更新最关键的部分：为什么选中了这个，为什么没选另外几个。
Spice的输出不再是:
“我建议你…”
而是把 comparison 本身显式化：
- 哪些 candidate 被 veto 了
- 哪些 candidate 可行，但在当前 tradeoff 下没有胜出
- 最后被选中的 candidate，主要依据是什么
这里不是说“把推荐理由写详细了一点”或者“补了一段explanation“，why A, not B 不再是一段解释文本，而是 decision object 里可追踪的结构化字段。。
图31538×168 10.5 KB
上面两张图展示的是Spice把decision从黑盒里拿出来了。
而图三想说的其实是这个 decision object 后面怎么接 execution layer，这个object不止是纸上谈兵，而是已经接入真实executor的完整闭环且它还能跨 execution boundary 进入执行链路。
这也是我为什么一直在不停的解释Spice不是orchestration，不是一个Agent编排架构，Spice只负责decision，Hermes/OpenClaw/CC/Codex等这类executor才负责execution。中间通过SDEP进行通信和链接。
更新总结
这次更新补上的，其实是 Spice 之前缺的一层：不是让 Spice 更会“说”，而是让 Spice 第一次把 decision 拿到了台面上，他还没有解决所有决策问题，但至少先把“为什么选 A 不选 B”变成了一个系统里可以被观察、比较、追踪的对象。只有让decision先显式的成为系统对象，后面才有可能做好decision evolution。
写在最后
无论是和佬友们的交流还是和空系的思想碰撞，都让我看Spice看的更清晰更具体。
Spice的愿景依然没变：
感知万物，做最适合你的决策，你的“AI大脑”
还是想做 decision layer above agents，还是想把决策和执行分开 evolution。
当前最重要的把“decision 到底是什么”先做成一个能被系统操作的对象”这一步我们已经补上了。
后面我们还会继续补：
- 更强的 simulation / consequence modeling
- 更真实的 decision feedback loop
- 以及更强有力证明决策更好的benchmark
我们要从让decision可以被系统操作这一步开始，迈向真正的让decision可以持续的进化，变得更好。
感谢佬友们的支持和鼓励，欢迎大家持续 网友解答：
--【壹】--：
重新编辑了一下，前面写的不是很好，期待和L友们交流！
--【贰】--：
更多spice相关可以看我第一篇帖子或者去看GitHub，有任何不懂或者问题都可以直接问我呀[开源] 执行层agent爆发引发思考，于是我做了Spice（小辣椒）这个开源项目... - #91，来自 Jiaa
--【叁】--：
没看懂，有点点收获，但不妨碍我想说大佬 666
--【肆】--：
更多Spice的相关内容可以去看我的第一篇帖子！[开源] 执行层agent爆发引发思考，于是我做了Spice（小辣椒）这个开源项目... - #91，来自 Jiaa
--【伍】--：
我的帖子没有任何AI润色或AI生成，全部是我自己手写各位佬友…
GitHub：GitHub - Dyalwayshappy/Spice: percept everything and make the 'best' decision for you. Your second 'brain' 感知万物，做最适合你的决策，你的“第二大脑” · GitHub