- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
各位佬友好啊，我是Jia，一名有9年经验的00后coder，距离Spice的首次亮相已经过去一个多月时间了，这一个月我参加了一些活动，去跟大家交流Spice及我的想法，有投资人朋友，技术大牛同时也有很多来自各行各业对AI感兴趣的朋友跟我交流探讨，各位的建议与支持我都记在心中，希望这次的更新与改变能让你们感到惊艳。
1. 关于Spice
Spice的概念来源于执行层agent的爆发以及多Agent改变工作方式的今天，我还是分几点来讲：
-
执行层Agent的局限：现在的agent对于大家来说是替代大家执行任务的工具（可以帮助你写代码，查资料，做记录等等），这些大多由ReAct或RL等方法论构建的Agent我把他统称为执行层工具，即人类输入意图，工具代理执行任务，当然这里面有很多很精彩的设计，比如openclaw的出现提出用更好的gateway去改变entrance，让你可以随时随地的操作你的agent执行任务（只要你的runtime在运行），这是目前市面上大多数Agent的设计理念和价值，人类仍然在决定“做什么”，agent只是负责“怎么做”
-
执行与决策黑盒：正因为目前Agent的设计方法论，无论harness或是任何Agent build，决策和执行依然处于黑盒状态，即Agent完成任务的过程是完全不可审计，不可回溯的，这也导致了目前关于Agent的benchmark只能从result反推，我们只能去衡量一个Agent的执行任务能力，但他在loop中使用任何tool call的原因我们无法清晰的明白
-
关于信号：随着执行层Agent的能力越来越强，我们可选用的Agent越来越多，自然而然的有越来越的多Agent infra做Agent编排，A2A，memory等，这意味着Agent从一个最早的chat bot 演变成了一个更全能更智能的代理，Agent已经从一个少部分人使用的工具变成要深入大家工作和生活的新入口，需要接收的signal越来越多，需要更强的context和memory能力，如何在越来越多的复杂信号中筛选出“有效信号”，更低的tokens使用成本，长期有效的存在于我们的生活和工作中会是下一个难题。
这三点构成了我做spice的想法，于是一个月前有了我们的第一次亮相，他像是一个看起来很厉害但不知道能做什么概念，他很空，也正因为是这样才有了我们的这一次完善。
2. 现在的Spice
为了让Spice不再只是一个很大的概念，我把Spice变成了一个可以30s就setup使用的Agent，他仍然遵循着以前的那套逻辑架构和我们的设计，仍然可以感知你的“世界信号”，Spice不试图替代执行Agent，而是让决策和执行不再在黑盒中展开，你可以清晰的看到基于你的state和intent决策是怎样产生和对比以及选择的原因，从这一刻开始Agent的决策变的显式，可审计，可回溯，可进化。
关于交互：现在的spice是一个可以直接运行在终端里的agent，像其他agent一样你可以快速setup，配置llm，permisiion以及一些专属于spice概念的配置：
- decision.md (决策偏好)
- executor（执行层agent：codex，claude code，hermes）
- perception(manul input, open chronicle)
几个关键变化：
Spice 开始具备通用感知能力
Spice 可以接收用户输入，也可以读取外部信号，比如 URL、命令输出、桌面上下文等。
这些信息不会直接触发执行，而是先变成 Spice 能理解的“观察”，再进入决策流程。
Spice现在不是看到变化就立刻行动，而是先问：
这个变化意味着什么？现在应该做什么？
Spice 不再绑定某个具体场景
早期版本更像是某个特定场景下的决策 demo，现在 Spice 抽象成了一个 General Decision Runtime。
不管输入来自哪里，最后都会进入统一的状态、候选方案、模拟、比较、选择流程。
Decision Card 让“为什么这样选”变得可见
很多Agent会直接给答案或在loop中完成task，而Spice 更关心的是这个答案是怎么来的。
他会展示：有哪些候选方案，推荐，为什么推荐，为什么其他方案没有胜出，风险和预期结果是什么。
Spice的重点不只是完成任务回答问题，而是把decision-making的过程显式化。
执行层可以交给外部 Agent
Spice 自己不是执行层 Agent
它负责判断：什么值得做，为什么要做，风险是什么，应该交给谁做
真正执行可以交给：
- dry_run
- Codex
- Claude Code
- Hermes
- 或未来任何 SDEP-compatible executor
默认的 dry_run 是安全模式，适合大家先测试完整链路。
总的来说：
Spice想做的不是另一个执行Agent，而是执行层Agent前面的决策大脑。
3. 测试时的dogfooding
这是一个比较有意思的分享，我们在测试的时候尝试用Spice去构Spice自己的下一步，我们有三个不同的方向，state as context，perception以及execution handoff选其中一个作Spice发展的下一步，我们记录了decision的形成，最后Hermes作为executor完成了这个小更新
4.如果你想快速体验
如果你想最快体验，可以这样或者去GitHub主页fork：
pip install spice-runtime
spice setup
spice shell
进入shell后像用普通agent一样问你想问的问题，Spice会默认给出自然语言建议，同时保留 /details、/sources、/json 这些审计入口。
5. Spice 和普通 Agent 有什么不同
很多人第一次听到 Spice，可能会把它理解成另一个 Agent wrapper，或者一个多 Agent 编排框架，但这其实不是我们team想做的事情。
普通执行类agent关心的问题是：
给我一个task，我如何完成task
编排框架更关心的是：
如何让不同agent在完成同一个task的时候负责不同的sector
而Spice更关心的是：
面对这个task和目前的state，为什么应该做A，而不是选择B
这也是 Spice 和执行层 Agent 最大的区别
Spice 不是为了替代 Codex、Claude Code、Hermes、OpenClaw 这样的执行 Agent。相反，Spice 希望站在它们之前，成为一个 decision layer：
- 先感知和整理上下文
- 再生成多个候选方向
- 比较收益、风险、成本和 confidence
- 展示为什么选择某一个方案
- 保留证据和审计入口
- 最后再决定是否交给 executor 执行
所以 Spice 不是“让 Agent 多做一步”或是优化 Agent 的执行结果，而是让 Agent 在执行之前多一个可见、可控、可回溯的决策过程。
随着 Agent 更深入我们的工作和生活，甚至逐渐成为很多人的主要工作入口，它面对的上下文会越来越复杂，能调用的工具会越来越多，产生影响的范围也会越来越大。
这时候我们真正需要的，不只是一个更强的执行器来完成任务，而是一套能回答它为什么选择这个行动？它的选择基于哪些信号和evidance？如果结果不好我们应该优化什么等这些问题的机制。
如果这些过程都藏在 Agent loop 里，我们只能从最终结果反推问题。但当决策过程被记录成 Decision Card，被 /sources、/why、/details sim 保留下来，Agent 的错误就不再只是一次失败的执行，而会变成可以复盘、可以调参、可以进化的决策样本。
这也是我认为 Spice 长期有价值的地方：它不是替 Agent 执行，而是让 Agent 的行动变得可解释、可审计，并最终可个性化优化，让他更有效的存在于我们每个人不同的世界内。
6.写在最后
这次发出来跟上次截然不同，我不希望大家只是认同我们的概念或者想法，而是希望大家真实的去看看Github repo，Star
并fork下来玩玩看，给我们更多的建议和反馈。
他应该还有很多bug和很多做的不够深的地方，如果你们也对Spice感兴趣，也欢迎疯狂给我们提PR，当然如果你觉得这个方向不好是错误的，也可以直接和我们探讨，这都是对我们最大的支持。感谢各位佬友的支持，期待大家的反馈
GitHub - Dyalwayshappy/Spice: A decision brain for agentic systems: perceive...
A decision brain for agentic systems: perceive context, compare options, and control execution.
4 个帖子 - 2 位参与者