万物皆插件之后， Agent 系统里什么不能跟着变？

DeepSeek Harness 发布后，“Everything is a plugin”很快成为 Agent 开发者讨论最多的一句话之一。

模型、工具、Skills 、会话、沙箱、文件系统、编排和 UI 都可以作为插件替换和组合。项目发布后也很快获得了 7 万多个 GitHub Star 。

这个方向很有吸引力。模型升级了可以换模型，工具不合适可以换工具，业务需求变化也不用重建整个 Agent 。开发者终于不用把所有能力焊死在一套技术栈里。

我们团队正在做 ZGI ，一个面向 Agent 运行与落地的 Runtime 。在接触客户项目的过程中，我们发现，组件可以灵活变化，但有些东西不能跟着一起漂移。

首先是身份和权限。换了一个工具，不应该让 Agent 突然获得更多数据权限；增加一个 Skill ，也不能顺便绕过原来的访问边界。

其次是执行状态。一个任务可能已经写入数据库、发送通知或者调用了外部系统。如果中途更换模型或某个组件发生故障，系统需要知道哪些步骤已经完成。否则简单地“再跑一次”，可能意味着重复创建订单、重复发送消息，甚至重复扣款。

审批规则也应该保持稳定。涉及付款、删除数据、修改关键记录或对外发送内容时，无论背后调用了哪个模型、工具或插件，都应该经过相同的确认流程。

运行记录也是一样。组件可以来自不同开发者，但谁调用了什么、使用了哪些数据、执行结果是什么，都需要进入一套统一的记录。出了问题，不能只留下一句 “Something went wrong”。

所以我们现在的理解是：插件决定 Agent 可以组合哪些能力，Runtime 则负责保证这些能力在变化之后，系统仍然能够被控制、追踪和恢复。两者不是替代关系，而是解决不同层面的问题。

这也是我们构建 ZGI 时重点处理的一层。ZGI 将模型、知识库、数据库、工具、Skills 和可视化工作流放在一个支持自托管的工作空间中，并通过权限、运行状态、人工确认、日志和沙箱执行，承接 Agent 进入真实业务后的运行问题。

ZGI 主要使用 Go 构建，已经在一些客户项目中持续验证。代码公开接近一个月，目前在 GitHub 上获得了 300 多个 Star 。项目还在早期阶段，很多地方仍在完善。

如果你也在开发 Agent 应用，欢迎体验 ZGI 、查看代码，或者直接告诉我们哪些地方还不够好。功能建议、GitHub Issue ，以及对 Agent Runtime 这条路线的看法。

https://github.com/zgiai/zgi