人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载导读本文是 Agent Substrate 项目关于集成仓库Integration Repositories的官方结构约定回答了三个核心问题端到端集成代码应该放在哪里核心仓库、agent-substrate组织下的独立仓库还是组织之外、仓库应该如何命名能力命名 vs 集成命名以及明确的避免清单、核心功能的缺口如何回流核心先行的上游策略禁止在集成仓库里打补丁。读者读完本文后将掌握一套可直接复用的多仓库治理模式如何为真实运行在 Agent Substrate 上的工作负载划分代码边界、如何用命名传达能力的真实范围、如何保证官方集成始终构建在已发布的核心版本之上。配套的counter、sandbox等仓库内示例与docs/roadmap.md中的集成路线图可以让你在仓库内找到这套规范的落地实例。背景为什么需要一套成文的仓库约定Agent Substrate 是一个面向大规模 Agent 部署的运行时环境提供沙箱生命周期管理秒级 suspend/resume、微虚拟机与 gVisor 等多种沙箱技术以及把 Agent 重度多路复用到底层计算资源上的能力。此前仓库内的所有示例都足够小可以放在被它们验证的代码旁边例如demos/下的演示。但随着项目开始获取第一批真正的端到端集成——那些运行在 Substrate 之上而非演示 Substrate的工作负载——情况发生了变化。真实的集成具备与核心演示完全不同的特征它们携带自己的容器镜像、自己的依赖、自己的发布节奏甚至可能有自己的维护者。如果不用文字把约定固定下来那么谁先建仓库谁就立规矩第一个被创建的仓库会成为后续所有仓库的默认先例。docs/integration-repos.md这份文档的价值就在于把选择变成有意识的决策而不是让偶然事件决定组织形态。从 docs/roadmap.md 的 Integrations 部分可以看到这种压力的具体来源Agent Executor在 Kubernetes 上部署 AX、Agent Development KitADK原生绑定、LangChain 远程执行 Provider、原生 MCP Server 托管、Actor-to-ActorA2A调用模型等都是重量级、跨仓库的集成工作。这些工作负载显然无法全部塞进核心仓库规范必须先行。代码放哪里三条清晰的边界规范用测试来划第一条线——判断一个东西是否留在核心仓库标准是运行它不需要 API 密钥、不需要外部服务、不需要第三方账户。留在核心仓库平凡演示与无密钥测试桩满足上述测试的平凡演示trivial demos和无密钥 API 练习器keyless API exercisers继续留在核心仓库。文档明确给出了两类典型counter 演示即 demos/counter 目录下的有状态计数器应用。它是一个简单的 Go HTTP 服务器counter.go每次请求同时递增两个计数器——一个在进程内存里一个在持久化卷上的文件里并借助模板中onCommit: SNAPSHOT_CONTENT_SCOPE_FULL的 Full 作用域快照见 counter-template.yaml.tmpl把进程内存与持久卷一起捕获从而在 suspend/resume 之后两个计数器都能从原值继续。CI 用来驱动 create、resume、suspend 生命周期流程的 mock即内部 e2e 测试设施例如 internal/e2e/fixtures/testserver 下的 HTTP/gRPC/WebSocket 测试服务及其模板。它们没有外部依赖因此天然适合留在核心仓库内被 CI 直接使用。从源码结构看demos/sandbox有状态沙箱执行环境演示也属于这一类——虽然它允许在沙箱内执行任意命令但本身同样是无外部账户依赖的演示因而与 counter 一起留在demos/下。独立仓库非平凡的端到端集成非平凡的端到端集成获得自己在agent-substrate组织下的独立仓库一个集成一个仓库one repository per integration代码、容器镜像、清单manifests和 SDK 全部放在里面。原因有二这类集成太大无法塞进核心仓库独立仓库让集成可以拥有自己的维护者而无需向维护者授予核心仓库的访问权限。组织之外社区维护的集成与概念验证agent-substrate组织内的所有内容都被视为官方内容必须遵守本文档的标准。任何人欢迎自建并自行托管集成——项目对此持欢迎态度——但是把项目品牌之下、而项目并不认为是官方的内容带进来会让用户困惑。因此组织只容纳项目自己维护的集成。社区维护的集成和独立概念验证proof of concept放在组织之外也正因为它们需要携带自己的补丁详见下文上游优先。为什么不是第二个组织一个常见的直觉是再建一个子组织不就行了。规范明确否定了这一点GitHub 只支持一级组织父子关系嵌套组织在平台层面根本不可用兄弟组织sibling org会引入额外的 onboarding 和访问管理开销而数量不多的几个平级仓库放在agent-substrate下完全没有这些成本。归属一览表对象归属Counter 演示、CI 使用的无密钥生命周期 mock核心仓库非平凡端到端集成代码、镜像、清单、SDKagent-substrate/name集成需要的核心修复或新配置项向核心仓库提 PR社区维护的集成或概念验证agent-substrate组织之外命名规范名字应当恰如其分命名只有两种情况取决于仓库实际上是什么能力命名Capability-named提供通用 Substrate 能力当一个仓库提供的是 Substrate 的通用能力只不过目前恰好只有一个实现时用能力命名。规范给出的取舍示例execution-sandbox优于sandbox太宽泛暗示覆盖范围超出任何单一仓库的实际能力也优于某个厂商的产品名太窄把通用能力绑定到单一实现上。集成命名Integration-named集成一个具体的开源项目当仓库集成的是某个具体的开源项目时用项目名命名而不是项目背后的厂商名——例如hermes而不是发布 Hermes 的那个组织名。开源项目名的边界为什么专有产品不能用于集成命名这里有一条严格边界集成命名只适用于开源项目。理由很严谨开源项目的名字指代任何人都能阅读、运行、fork 的东西用它做描述性命名不声称任何东西专有产品的名字是品牌借用品牌隐含着背书endorsement或兼容性承诺compatibility promise而双方都没有做出过这种承诺因此当被集成对象是专有产品时改用能力命名execution-sandbox而不是厂商的产品名。避免清单规范给出了四个要避开的命名陷阱通用名generic names如sandbox、plugins——声称的覆盖面远超任何单一仓库实际覆盖的范围过度具体名over-specific names失败方式正好相反——它们会把读者从本来能用的方案旁边引开。一个经常被用于代码执行的沙箱本质上仍然是一个通用执行沙箱把它命名为code-execution-sandbox会诱导不同负载的读者得出这不适合我的结论。名字应该刚好够描述事物本身不能再长克隆专有 API 或品牌的名字这会让项目悄悄背上追赶别人命名决策的包袱-integration后缀这个类别里的每个仓库都是集成后缀不携带任何信息——是hermes不是hermes-integration。商标与免责声明即使是开源项目名字也是描述性使用不构成从属关系声明仓库 README 应当说明该项目与上游项目无关联商标归各自所有者所有。品牌与政策边界要在仓库创建之前理清而不是之后——因为一旦仓库以某个名字被创建、被引用、被链接改名成本就高得多了。上游优先核心变更永远先落地这是整份规范中工程实践味道最重的一节。真实集成会暴露核心的真实缺口real gaps in core在 Substrate 上构建长期运行的 Agent暴露了**可配置超时configurable timeouts和黄金快照预热golden-snapshot warmup**的需求对应 PR #487还撞上了suspend-safe 的 Actor 网络通信问题对应 issue #465。agent-substrate下的仓库不会把这类缺口当作补丁随身携带。规则是绝对的一个集成仓库构建并运行在已发布的核心版本之上不 fork 核心、不携带供应商补丁、不依赖任何未合并的变更。当集成需要核心尚未提供的能力时核心变更先落地集成随后依赖包含该变更的已发布版本。为什么这条规则可以如此绝对因为我们自己就是自己的上游——同一个项目同时托管两个仓库所以不存在补丁必须等下游其他人行动的时间窗口。一个依赖我们自己核心缺失的变更的官方集成是尴尬embarrassing而不只是不便inconvenient的。相比之下组织之外的独立概念验证可以自由携带任何补丁——那种自由本身就是它们应该待在组织之外的原因之一。核心的设计偏好可配置化默认值不变规则的推论是一条对核心的设计偏好当核心行为阻塞集成时优先把该行为做成可配置项且保持默认值不变configurable with defaults unchanged而不是为调用方特判special-casing。这样先在核心落地就是一条短路径而不是阻塞点——集成可以通过配置获得所需行为其他既有用户因为默认值不变而完全不受影响。这正是 demos/counter/counter-template.yaml.tmpl 中onCommit快照策略、counter.go中--extra-port、--file-counter-directory等 pflag 参数见 counter.go所体现的模式核心能力通过显式配置暴露而不是为某个调用方写死分支。两个验证性案例规范不是纸面文章文档特意强调这两个案例的作用是验证这套约定validate the convention而不只是遵从它agent-substrate/execution-sandbox—— 能力命名一个构建在 Substrate 之上的沙箱化执行服务精神上与现有的 sandbox 产品一致但不模仿任何一家现有产品的 API。名字刻意停在能力这一层代码执行只是它服务的众多工作负载之一不是它的边界。这正是对过度具体名陷阱的正面回答——如果叫code-execution-sandbox就把自己的未来工作负载挡在门外了。agent-substrate/always-on-agent—— 连接保持型 Agent一个保持连接的 Agent一个多租户网关multi-tenant gateway加上一个可 suspend 的按会话 Actorsuspendable per-conversation actor。它的第一个实现基于某个第三方 Agent 运行时但能力比任何一个运行时都活得久所以仓库按能力命名而非按该运行时命名。文档特别指出这正是仅限开源项目这条规则要捕获的边界情况——即使底层运行时是第三方专有产品仓库名依然落在能力层。尚未定论仓库创建与访问权限规范最后留了一个开放问题刻意排除在本文范围之外以免阻塞第一批仓库的创建仓库创建与访问谁负责创建集成仓库谁授予按集成划分的维护者访问权限这是一个留给维护者决策的组织治理问题与代码布局、命名和上游策略正交可以在第一批集成落地后根据实际经验再定。结语从规范到路线图docs/integration-repos.md是一份短小但自洽的治理文档它与项目的现状和未来相互印证现状侧留在核心仓库的demos/counter含微虚拟机变体 counter-microvm-template.yaml.tmpl和demos/sandbox完全满足无外部密钥、无第三方账户的归属测试是规范的直接例证安全侧docs/threat-model.md 中的 T-42 威胁项把与威胁检测系统的集成列为安全方向这类集成一旦落地按本文规范应获得自己的独立仓库未来侧docs/roadmap.md 的 Integrations 章节列出了 ADK 原生绑定、LangChain Provider、MCP Server 托管、A2A 调用模型等重量级集成——当它们从路线图变为现实时一个集成一个仓库、能力名或开源项目名、核心先行这套约定就是它们的第一份工程约束。对于任何正在扩张的开源项目这套归属测试 双轨命名 上游优先的组合都值得借鉴它用最小的规则集同时保护了核心仓库的可维护性、集成仓库的自主性以及项目品牌的可信度。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测 本篇技术指南围绕 Ag人工智能AI AgentAgent 沙箱云原生容器运行时零信任WinApps旧电脑部署Windows应用4GB内存2核起步的完整方案WinApps旧电脑部署Windows应用4GB内存2核起步的完整方案 本文用WinApps在4GB内存、双核的旧Linux电脑上装Windows 11虚拟机桌面应用虚拟化Agent Substrate 代码布局指南顶层目录结构与 Go 包放置决策规则Agent Substrate 代码布局指南顶层目录结构与 Go 包放置决策规则 Agent Substrate 是一个以 Go 为主、围绕 Kubernet人工智能AI AgentAgent 沙箱云原生容器运行时零信任创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agent Substrate 集成仓库规范：agent-substrate 组织下的代码归属、命名与上游优先策略
人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载导读本文是 Agent Substrate 项目关于集成仓库Integration Repositories的官方结构约定回答了三个核心问题端到端集成代码应该放在哪里核心仓库、agent-substrate组织下的独立仓库还是组织之外、仓库应该如何命名能力命名 vs 集成命名以及明确的避免清单、核心功能的缺口如何回流核心先行的上游策略禁止在集成仓库里打补丁。读者读完本文后将掌握一套可直接复用的多仓库治理模式如何为真实运行在 Agent Substrate 上的工作负载划分代码边界、如何用命名传达能力的真实范围、如何保证官方集成始终构建在已发布的核心版本之上。配套的counter、sandbox等仓库内示例与docs/roadmap.md中的集成路线图可以让你在仓库内找到这套规范的落地实例。背景为什么需要一套成文的仓库约定Agent Substrate 是一个面向大规模 Agent 部署的运行时环境提供沙箱生命周期管理秒级 suspend/resume、微虚拟机与 gVisor 等多种沙箱技术以及把 Agent 重度多路复用到底层计算资源上的能力。此前仓库内的所有示例都足够小可以放在被它们验证的代码旁边例如demos/下的演示。但随着项目开始获取第一批真正的端到端集成——那些运行在 Substrate 之上而非演示 Substrate的工作负载——情况发生了变化。真实的集成具备与核心演示完全不同的特征它们携带自己的容器镜像、自己的依赖、自己的发布节奏甚至可能有自己的维护者。如果不用文字把约定固定下来那么谁先建仓库谁就立规矩第一个被创建的仓库会成为后续所有仓库的默认先例。docs/integration-repos.md这份文档的价值就在于把选择变成有意识的决策而不是让偶然事件决定组织形态。从 docs/roadmap.md 的 Integrations 部分可以看到这种压力的具体来源Agent Executor在 Kubernetes 上部署 AX、Agent Development KitADK原生绑定、LangChain 远程执行 Provider、原生 MCP Server 托管、Actor-to-ActorA2A调用模型等都是重量级、跨仓库的集成工作。这些工作负载显然无法全部塞进核心仓库规范必须先行。代码放哪里三条清晰的边界规范用测试来划第一条线——判断一个东西是否留在核心仓库标准是运行它不需要 API 密钥、不需要外部服务、不需要第三方账户。留在核心仓库平凡演示与无密钥测试桩满足上述测试的平凡演示trivial demos和无密钥 API 练习器keyless API exercisers继续留在核心仓库。文档明确给出了两类典型counter 演示即 demos/counter 目录下的有状态计数器应用。它是一个简单的 Go HTTP 服务器counter.go每次请求同时递增两个计数器——一个在进程内存里一个在持久化卷上的文件里并借助模板中onCommit: SNAPSHOT_CONTENT_SCOPE_FULL的 Full 作用域快照见 counter-template.yaml.tmpl把进程内存与持久卷一起捕获从而在 suspend/resume 之后两个计数器都能从原值继续。CI 用来驱动 create、resume、suspend 生命周期流程的 mock即内部 e2e 测试设施例如 internal/e2e/fixtures/testserver 下的 HTTP/gRPC/WebSocket 测试服务及其模板。它们没有外部依赖因此天然适合留在核心仓库内被 CI 直接使用。从源码结构看demos/sandbox有状态沙箱执行环境演示也属于这一类——虽然它允许在沙箱内执行任意命令但本身同样是无外部账户依赖的演示因而与 counter 一起留在demos/下。独立仓库非平凡的端到端集成非平凡的端到端集成获得自己在agent-substrate组织下的独立仓库一个集成一个仓库one repository per integration代码、容器镜像、清单manifests和 SDK 全部放在里面。原因有二这类集成太大无法塞进核心仓库独立仓库让集成可以拥有自己的维护者而无需向维护者授予核心仓库的访问权限。组织之外社区维护的集成与概念验证agent-substrate组织内的所有内容都被视为官方内容必须遵守本文档的标准。任何人欢迎自建并自行托管集成——项目对此持欢迎态度——但是把项目品牌之下、而项目并不认为是官方的内容带进来会让用户困惑。因此组织只容纳项目自己维护的集成。社区维护的集成和独立概念验证proof of concept放在组织之外也正因为它们需要携带自己的补丁详见下文上游优先。为什么不是第二个组织一个常见的直觉是再建一个子组织不就行了。规范明确否定了这一点GitHub 只支持一级组织父子关系嵌套组织在平台层面根本不可用兄弟组织sibling org会引入额外的 onboarding 和访问管理开销而数量不多的几个平级仓库放在agent-substrate下完全没有这些成本。归属一览表对象归属Counter 演示、CI 使用的无密钥生命周期 mock核心仓库非平凡端到端集成代码、镜像、清单、SDKagent-substrate/name集成需要的核心修复或新配置项向核心仓库提 PR社区维护的集成或概念验证agent-substrate组织之外命名规范名字应当恰如其分命名只有两种情况取决于仓库实际上是什么能力命名Capability-named提供通用 Substrate 能力当一个仓库提供的是 Substrate 的通用能力只不过目前恰好只有一个实现时用能力命名。规范给出的取舍示例execution-sandbox优于sandbox太宽泛暗示覆盖范围超出任何单一仓库的实际能力也优于某个厂商的产品名太窄把通用能力绑定到单一实现上。集成命名Integration-named集成一个具体的开源项目当仓库集成的是某个具体的开源项目时用项目名命名而不是项目背后的厂商名——例如hermes而不是发布 Hermes 的那个组织名。开源项目名的边界为什么专有产品不能用于集成命名这里有一条严格边界集成命名只适用于开源项目。理由很严谨开源项目的名字指代任何人都能阅读、运行、fork 的东西用它做描述性命名不声称任何东西专有产品的名字是品牌借用品牌隐含着背书endorsement或兼容性承诺compatibility promise而双方都没有做出过这种承诺因此当被集成对象是专有产品时改用能力命名execution-sandbox而不是厂商的产品名。避免清单规范给出了四个要避开的命名陷阱通用名generic names如sandbox、plugins——声称的覆盖面远超任何单一仓库实际覆盖的范围过度具体名over-specific names失败方式正好相反——它们会把读者从本来能用的方案旁边引开。一个经常被用于代码执行的沙箱本质上仍然是一个通用执行沙箱把它命名为code-execution-sandbox会诱导不同负载的读者得出这不适合我的结论。名字应该刚好够描述事物本身不能再长克隆专有 API 或品牌的名字这会让项目悄悄背上追赶别人命名决策的包袱-integration后缀这个类别里的每个仓库都是集成后缀不携带任何信息——是hermes不是hermes-integration。商标与免责声明即使是开源项目名字也是描述性使用不构成从属关系声明仓库 README 应当说明该项目与上游项目无关联商标归各自所有者所有。品牌与政策边界要在仓库创建之前理清而不是之后——因为一旦仓库以某个名字被创建、被引用、被链接改名成本就高得多了。上游优先核心变更永远先落地这是整份规范中工程实践味道最重的一节。真实集成会暴露核心的真实缺口real gaps in core在 Substrate 上构建长期运行的 Agent暴露了**可配置超时configurable timeouts和黄金快照预热golden-snapshot warmup**的需求对应 PR #487还撞上了suspend-safe 的 Actor 网络通信问题对应 issue #465。agent-substrate下的仓库不会把这类缺口当作补丁随身携带。规则是绝对的一个集成仓库构建并运行在已发布的核心版本之上不 fork 核心、不携带供应商补丁、不依赖任何未合并的变更。当集成需要核心尚未提供的能力时核心变更先落地集成随后依赖包含该变更的已发布版本。为什么这条规则可以如此绝对因为我们自己就是自己的上游——同一个项目同时托管两个仓库所以不存在补丁必须等下游其他人行动的时间窗口。一个依赖我们自己核心缺失的变更的官方集成是尴尬embarrassing而不只是不便inconvenient的。相比之下组织之外的独立概念验证可以自由携带任何补丁——那种自由本身就是它们应该待在组织之外的原因之一。核心的设计偏好可配置化默认值不变规则的推论是一条对核心的设计偏好当核心行为阻塞集成时优先把该行为做成可配置项且保持默认值不变configurable with defaults unchanged而不是为调用方特判special-casing。这样先在核心落地就是一条短路径而不是阻塞点——集成可以通过配置获得所需行为其他既有用户因为默认值不变而完全不受影响。这正是 demos/counter/counter-template.yaml.tmpl 中onCommit快照策略、counter.go中--extra-port、--file-counter-directory等 pflag 参数见 counter.go所体现的模式核心能力通过显式配置暴露而不是为某个调用方写死分支。两个验证性案例规范不是纸面文章文档特意强调这两个案例的作用是验证这套约定validate the convention而不只是遵从它agent-substrate/execution-sandbox—— 能力命名一个构建在 Substrate 之上的沙箱化执行服务精神上与现有的 sandbox 产品一致但不模仿任何一家现有产品的 API。名字刻意停在能力这一层代码执行只是它服务的众多工作负载之一不是它的边界。这正是对过度具体名陷阱的正面回答——如果叫code-execution-sandbox就把自己的未来工作负载挡在门外了。agent-substrate/always-on-agent—— 连接保持型 Agent一个保持连接的 Agent一个多租户网关multi-tenant gateway加上一个可 suspend 的按会话 Actorsuspendable per-conversation actor。它的第一个实现基于某个第三方 Agent 运行时但能力比任何一个运行时都活得久所以仓库按能力命名而非按该运行时命名。文档特别指出这正是仅限开源项目这条规则要捕获的边界情况——即使底层运行时是第三方专有产品仓库名依然落在能力层。尚未定论仓库创建与访问权限规范最后留了一个开放问题刻意排除在本文范围之外以免阻塞第一批仓库的创建仓库创建与访问谁负责创建集成仓库谁授予按集成划分的维护者访问权限这是一个留给维护者决策的组织治理问题与代码布局、命名和上游策略正交可以在第一批集成落地后根据实际经验再定。结语从规范到路线图docs/integration-repos.md是一份短小但自洽的治理文档它与项目的现状和未来相互印证现状侧留在核心仓库的demos/counter含微虚拟机变体 counter-microvm-template.yaml.tmpl和demos/sandbox完全满足无外部密钥、无第三方账户的归属测试是规范的直接例证安全侧docs/threat-model.md 中的 T-42 威胁项把与威胁检测系统的集成列为安全方向这类集成一旦落地按本文规范应获得自己的独立仓库未来侧docs/roadmap.md 的 Integrations 章节列出了 ADK 原生绑定、LangChain Provider、MCP Server 托管、A2A 调用模型等重量级集成——当它们从路线图变为现实时一个集成一个仓库、能力名或开源项目名、核心先行这套约定就是它们的第一份工程约束。对于任何正在扩张的开源项目这套归属测试 双轨命名 上游优先的组合都值得借鉴它用最小的规则集同时保护了核心仓库的可维护性、集成仓库的自主性以及项目品牌的可信度。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测 本篇技术指南围绕 Ag人工智能AI AgentAgent 沙箱云原生容器运行时零信任WinApps旧电脑部署Windows应用4GB内存2核起步的完整方案WinApps旧电脑部署Windows应用4GB内存2核起步的完整方案 本文用WinApps在4GB内存、双核的旧Linux电脑上装Windows 11虚拟机桌面应用虚拟化Agent Substrate 代码布局指南顶层目录结构与 Go 包放置决策规则Agent Substrate 代码布局指南顶层目录结构与 Go 包放置决策规则 Agent Substrate 是一个以 Go 为主、围绕 Kubernet人工智能AI AgentAgent 沙箱云原生容器运行时零信任创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考