Hermes + Spice来了！各位佬友久等了！
最近有一个很明显的趋势是：Agent的执行能力在快速进化
从 Openclaw 到 Hermes，任务执行质量在不断提升，尤其是Hermes的Agent evolution能力。
与此同时有一个问题也越来越明显：
我们都在解决“怎么做”，但“该做什么”，还没有真正被解决。
1. 关于“决策解耦”的大胆尝试
我们做了一次大胆的尝试：Spice + Hermes（via SDEP）。
现在大多数的Agent设计或方法论，其实都有一个共同点：“决策”和“执行”是耦合在一起的。
比如ReAct：它把 reasoning 和 acting 放在同一个 loop 里。
它很强，但“该做什么”和“怎么做”，没有清晰的边界。
也就是说：决策是隐式的，执行是耦合的，结果也很难结构化回流。
所以我们做了一件很简单的事情：把 ReAct 里的 Act，抽成一个独立的协议边界。
让“该做什么” → 由一个独立的决策层产生，把“怎么做” → 交给不同的 agent 去执行，他们中间通过一个明确的协议连接：SDEP
这就是我们做Spice + SDEP的出发点（
把“执行”与“决策”彻底解耦）
2. Hermes 控制执行进化，Spice 控制决策进化
这次Spice + Hermes尝试的核心不是“再做一个 Agent”，而是把 Agent 系统里常常混在一起的两件事拆开：
-
Hermes继续进化执行能力：入口、tools、skills、execution
-
Spice专注进化决策质量：state、simulation、权重、约束、取舍
-
SDEP作为中间的协议边界：把决策变成结构化执行请求，再把执行结果结构化回流
简单点来说：
-
Hermes 负责把事情做得更好。
-
Spice 负责判断什么事值得做、什么时候做、为什么做。
-
SDEP 负责让这两层不要混在同一个 Agent loop 里。
Hermes controls Agent Evolution, and Spice controls Decision Evolution.
3. 从黑盒 Loop 到透明逻辑结构
举个简单的例子：
当系统收到一个任务：处理这个 GitHub PR
在普通 Agent loop 里，这通常会变成一个连续过程：Agent 理解任务 → 自己判断要怎么做 → 调工具执行 → 总结结果
决策和执行发生在同一个黑盒 loop 里。
它到底是怎么决定：
- 现在处理？
- 先 triage？
- 直接修改代码？
- 还是先问用户确认？
这些判断通常藏在 prompt、上下文和 agent 自己的 reasoning 里。
而在 Spice + Hermes 里：
Spice先根据当前状态决定现在最合理的行动是什么，Hermes 只负责：把这个行动执行到最好，中间通过 SDEP，把决策变成结构化请求，执行结果再回流，影响下一次决策。
这次我们把 Spice 和 Hermes 做了一次真实组合。把“决策”和“执行”，变成两个独立的层。
在这个组合里：
-
Hermes负责接收外部消息、连接工具、调用执行层 Agent
-
Spice负责维护决策所需的 state，构建当前 decision context，模拟候选行动，并做最终 recommendation
-
SDEP负责把 Spice 的 recommendation 转成结构化执行请求，并把执行结果以 structured outcome 回流给 Spice，用于 decision evolution。Hermes 则保留执行过程、工具调用和 transcript，用于自己的 agent / execution evolution。
4. Same Brain, Different Agent
但这里有一点很重要：Spice 并不绑定 Hermes
Hermes 只是这次的一个 reference executor。
只要一个 Agent 能理解 SDEP，或者能通过 wrapper 被转成 SDEP，Spice 就可以把决策交给它执行。
也就是说，未来接入的可以是：OpenClaw，Claude Code，Codex以及未来的physical-world agent。
Spice 保持在 decision layer，外部 Agent 保持在 execution layer。
SDEP 则是它们之间的协议边界。
5. Spice 与它的 SDEP 标准
这件事重要的地方，不是我们把 WhatsApp、Hermes、Codex 接在了一起。
而是我们可能一直在优化 Agent 的“手”，
但忽略了它的“脑”。
执行层可以继续变得更强， 更快、更自动化、更通用，而决策层， 可以开始被单独建模、优化、甚至演化，这也是我们想推动 Spice和SDEP 的原因。
为什么推动Spice：
Agent 的执行能力正在快速进化，但“决策层”还没有真正独立出来。
现在大家都在让 Agent 更会做事：
-
更强的 tools
-
更长的 context
-
更好的 coding / browser / automation
但真正关键的问题是：
谁来决定现在该做什么？为什么做？执行结果如何影响下一次决策？
Spice 想做的不是另一个 execution agent，而是 agents 之上的 decision runtime。
它关注的是 state、simulation、preference、constraint、trade-off 和 decision evolution。
未来 AI 系统不只需要更强的执行能力，也需要一个更清晰的决策层。
为什么推动SDEP：
如果每个 execution agent 都有自己的调用方式、自己的返回格式、自己的失败语义，那么 decision runtime 很难真正变成一个独立层。
SDEP想做的事情很简单：
-
标准化 execute.request
-
标准化 execute.response
-
区分 protocol failure 和 task failure
-
让 outcome 可以被 decision layer 消化
-
让不同 execution agents 可以被替换
它不是为了替代 ReAct 或 RL。 它是为了给 decision layer 和 execution layer 之间留出一个清晰边界。
7. 欢迎来到 Spice 社区
这次我们已经把这套想法做成了一个可以跑的 reference integration。
目前 repo 里已经包含：
-
decision.md：用户可编辑的决策配置
-
examples/decision_hub_demo/：Spice-Hermes 组合中的demo domain
-
spice-hermes-bridge/：Spice接Hermes的参考桥接
-
schemas/sdep/v0.1/：SDEP JSON Schemas
-
examples/sdep_payloads/v0.1/：SDEP request / response 示例
-
examples/sdep_quickstart/：给 executor 作者的 SDEP quickstart
如果你想体验Spice + Hermes或把Spice接入不同domain，具体怎么运行、怎么接入、怎么实现 SDEP executor，可以直接看 GitHub README 和 repo 里的 quickstart。
如果你也觉得未来 Agent 系统不应该只继续堆 tools、堆 memory、堆 execution loop，而是需要一个更清晰的 decision layer，
欢迎 star / issue / PR，也欢迎评论区讨论！
7 个帖子 - 2 位参与者