JarvisCore

Hi Product Hunt，我是 Muyukani，Prescott Data 的创始人兼 CEO。我们打造基础设施，让 AI 在受监管行业里真正可用，而 JarvisCore 就是它底下的开源 runtime。

灵感来源：
我们试过的每个智能体框架都长一个样：一个主控智能体调度其他智能体，工具靠外挂 MCP server，API key 放在 .env 文件里，记忆要么无限增长，要么被截断。这种形态在 demo 里能用，但智能体一真跑起来就崩。

我们想解决的问题：
1. 主控编排器是单点故障，也是扩展上限。它一挂，整个智能体集群就全挂。
2. 每个 MCP server 都带自己那套 provider 认证接线。十个 provider 就是十份认证头疼。
3. 凭证放在 .env 文件里，最后会跑进智能体上下文、prompt 和 trace 里。
4. 记忆要么没上限，成本和噪音永远涨；要么有损，智能体只能靠碎片来推理。

它怎么演化来的：
我们拿真实预算在 JarvisCore 上跑自己的智能体，坏了就修，一个 release 一个 release 来。这带来了四个决定：

1. 没有主控智能体。智能体是去中心化 P2P mesh 里平等的 peer。它们互相发现、认领工作，也会接手挂掉 peer 的活。没有单点故障，加 peer 就能扩展。
2. 没有 MCP server。智能体自己写工具，JarvisCore 原生编排 provider 认证，所以智能体能跨任意 provider 认证。
3. 零信任凭证。我们的 broker Nexus 在调用时注入凭证。智能体永远看不到 key，也不依赖 .env 文件。
4. 有界、无损的记忆。智能体按曲线遗忘：用得多的留下，不用就淡出。记忆保持有界，又不会截掉智能体需要的东西。

为什么该用它：
如果你在构建必须无人值守运行、横跨很多系统、还得用真实凭证的智能体，JarvisCore 把上面四点都装进一个 Apache-2.0 package 里。先用三个属性起一个 AutoAgent，然后把同一份代码扩到多台机器上。

pip install jarviscore-framework

如果你的智能体已经跑出 demo 阶段，我很想知道你最先碰到的是什么崩掉。

调用时才注入凭证、让智能体永远看不到 key，这是我最想要的部分。key 泄漏到 prompt 和 trace 里才是真头疼。

“永远不用自己的 key”这个直觉是对的，把 auth 移到 broker，而不是把 secret 撒到每个智能体身上。但这样一来，在一个号称 peer-to-peer 的 mesh 里，broker 不就成了新的单点故障/单点攻击目标吗？如果它挂了或被攻破，智能体是不是就直接没能力对外调用了？还是说有条 fallback，不会悄悄又把静态 key 引回来？