跟各位佬友分享一下最近使用Hermes + Spice的经历，以及一次和朋友的Agent（空系）的深度交流。
写在开头
Agent的执行能力，生态发展真的是越来越强，跟朋友的这次思想碰撞让我发现，A2A也是个特别好玩的事情，朋友在睡觉你可以让你的Agent去找他的Agent对齐一些信息，拿到一些有用的context，但最重要的收获是逼我重新思考 Spice 当前最真实的价值。
一直在思考Spice的定位和Spice的发展，于是我自己跳出创始人视角去看我们的项目以及和朋友进行了一波A2A对话。下面是他的Agent（空系）看到Spice的第一反应
我仔细的思考了空系说的话，他的质疑是对的，**尤其是“结构本身不产生智能”，对于帮你做更好的决策是我们持续优化的目标，我们才刚刚开始，那我们不妨说的不要那么有愿景，就说目前Spice最直观的价值：把Decision抽离出来，变成一个可被系统观察，比较和追踪的对象。
这是我们做Spice的初衷，有很大一部分受上一个项目的影响，我们发现目前我们有了宏大的愿景即“brain above agent”，也已经有了相对完整的底层设施（runtime，SDEP，decision.md and Hermes integration），但总感觉中间还缺了什么，我们一直在强调要把agent里的执行和决策解耦合，要让决策和执行分开evolution，但目前的Spice repo里，只是从架构把决策抽象出来了，却还没有把它真正变成一个人能看懂的对象。我们缺的是让decision第一次变得 human-readable。所以有了下面这次更新。
更新内容
我这次更新没有解决什么大问题，而是先做了一个最小的可见层：Human-readable Decision Comparison。
不是新的candidate generation，新的simulation或是新UI，只是把已有的decision trace变成一个人可以读懂的comparison object，通俗易懂一点说：让你清晰的看到Spice为什么建议你选A不选B，依据到底是什么。
下面是我们这次更新后的一次测试demo：
这次demo的测试用例仍然很简单，用户眼下有一个立刻要处理的GitHub work item，但离下一个会议commitment只剩一个很短的时间，这时候系统要决定立刻处理，先快速trigger再defer，暂时忽略还是委托给可用的executor（这里的executor指的就是外部执行层agent）。
这几张图不是普通的终端输出，而是一个decision object。
在这个comparison object里，和这次decision相关的state，当前有哪些candidate，每个candidate的tradeoff / veto / constraint，最后为什么选中了这个选项、为什么没选另外几个，以及这个 decision 自己的 trace / id都被清晰的展示出来。
也就是说，它不只是告诉你“该怎么做”，而是把“为什么这么做”也清晰的展示给你看。
图一主要展示Spice 先把这次decision真正相关的 state 摊开，再把候选action一并列出来。重点不在于信息更多，而是哪些状态和条件真的在约束这次选择。
Spice不是直接从context里跳到一句建议，而是先把 decision-relevant state 和 candidate set显式展开。这一步很重要，因为后面的选择，不再像是黑盒里突然跳出来的结论，而是建立在一个可见的比较对象上。
图二是最关键的一部分，为什么选中了这个，为什么没选另外几个。
这里也是我觉得 Spice 这次更新最有意义的地方——不是 recommendation 本身，而是 comparison 被显式化了。
Spice的输出不再是“我建议你…”，而是哪些 candidate 被 veto 了，哪些 candidate 虽然可行但在当前 tradeoff 下不是最优，最后被选中的那个又是因为什么胜出的。
这里不是说“把推荐理由写详细了一点”或者“补了一段explanation“，这和LLM和Agent不一样，Spice把 why A, not B 变成了系统里一个可见、可比、可追踪的对象。
上面两张图想呈现给各位的是Spice 到底把什么东西从黑盒里拿出来了。
而图三想说的其实是这个 decision object 后面怎么接 execution layer，这个object不止是纸上谈兵，而是已经接入真实executor的完整闭环且它还能跨 execution boundary 进入执行链路。
这也是我为什么一直在不停的解释Spice不是orchestration，不是一个Agent编排架构，Spice只负责decision，Hermes/OpenClaw/CC/Codex等这类executor才负责execution。中间通过SDEP进行通信和链接。
更新总结
这次更新其实补了一层我们缺失的内容，不是让 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可以持续的进化，变得更好。
关于benchmark的内容我们已经筹划的差不多了，补齐几个重要sector后应该会具体出一篇帖子跑benchmark，各位大佬有关于benchmark设计的建议（即如何证明决策变得更好）也可以跟我多交流探讨，关于真实的integration reference，我们已经有通过whatsapp和Hermes组合的示例在GitHub，perception层只接了主动输入和GitHub的WebHook，大家可以根据具体需要扩大自己的感知层，架构清晰也比较简。（GitHub可以看我之前的帖子或者我一会分享到评论区
）
感谢佬友们的支持和鼓励，欢迎大家持续关注我们，我在LinuxDo感受到了无比的热情，欢迎大家跟我们一起讨论关于执行和决策之间的关系，关于建议，好的坏的我们都接受，期待宝贵反馈和思想碰撞！
2 个帖子 - 1 位参与者