尧图网站建设 
大多数 AI 平台的架构里模型调用和任务编排是绑死在一起的。你用某个平台的 Agent就只能调这个平台支持的模型用这个平台内置的工具链按照这个平台规定的流程走完一轮对话或一次任务。这带来一个很直接的问题当你想换一个模型运行时比如从云端 API 切到本地部署的 Ollama或者从 Claude Code 换成 Codex你大概率要在另一个平台上重建整套 Agent 配置。技能要重新挂身份要重新设上下文全部丢掉。OCTO 做架构设计的时候我们选了一条不同的路线把平台的职责收窄到两件事上身份管理和任务管理然后把模型调用和具体执行的部分完整地交给外部运行时。这篇文章拆解一下这个分层设计的具体逻辑以及它在技能挂载、Bot 接入、多 Agent 协作这几个场景下的实际效果。平台层只回答两个问题“是谁和做什么”OCTO 的平台层由四个模块组成IM 核心负责消息路由回路 ServerLoop Server管理任务生命周期智能层处理上下文拼装和策略分发Bot Framework 负责对接各种运行时的 Agent。在这四个模块里没有任何一个直接调用大模型 API。这个设计选择意味着平台层关心的是这个 Agent 叫什么名字、有什么能力标签、当前在哪个 Loop 里执行什么任务、任务进展到哪一步了。至于这个 Agent 底层跑的是 GPT-4o 还是 Qwen 还是本地的 Llama平台层完全不管。Agent 的身份信息通过 AgentCard名片来描述。一张 AgentCard 里标明了这个 Agent 具备的能力比如写代码、做数据分析、翻译、法务审核同时也挂载了它的技能包和运行时绑定关系。AgentCard 是平台层的东西它定义了 Agent 在 OCTO 生态里的身份但不限定这个 Agent 的底层实现方式。执行层独立出去之后运行时变成了可插拔的执行层在 OCTO 的架构里叫 OctoPush包含本地客户端和 Runtime 网关两部分。本地客户端跑在用户的机器上Runtime 网关负责管理运行时的注册、健康检查和状态同步。我们目前支持的运行时包括 OpenClaw、Claude Code、Codex、Hermes 等。每一种运行时都有自己的模型调用方式、自己的工具链、自己的 Agent 执行逻辑。OCTO 不去统一这些差异而是通过 Bot Framework 提供一个标准化的接入协议让任意运行时上跑的 Agent 都能以统一的身份出现在 OCTO 的 IM 和 Loop 里。一个开发团队可能同时在用 Claude Code 做代码生成、用 OpenClaw 跑日常运维任务、用一个自研的 Agent 做数据清洗这三个 Agent 分别在不同运行时上执行但在 OCTO 里它们都是有 AgentCard 的协作成员可以被拉进同一个 Loop参与同一个任务流。这种拆法还有一个不太显眼但比较实用的好处。运行时的健康管理和 Agent 的任务管理彻底分开了。一个运行时挂了或者需要升级不影响这个 Agent 在 Loop 里的任务状态重新绑定一个运行时就能接着跑。Runtime 网关会持续做健康检查和状态同步当某个运行时掉线的时候平台层只是把这个 Agent 标记为暂时不可用它的 AgentCard、已有的技能挂载、在 Loop 中的任务记录全部保留。等运行时恢复或者换了一个新的运行时注册上来绑定关系一更新任务继续推进。这和传统 AI 平台的做法形成了比较明显的对比。传统方案里模型挂了往往意味着整条链路中断因为任务编排逻辑、上下文管理、工具调用全部依赖同一个模型服务端点。OCTO 把这些依赖关系拆散了平台层的稳定性和运行时的稳定性互不影响。技能系统让 Agent 的能力变成可以拼装的零件OCTO 里的技能Skill是一种可复用的提示词包你可以把它理解成一段经过调试和验证的 system prompt 加上配套的工具调用说明打包成一个独立的单元挂到任意 Agent 上。技能的设计逻辑和传统 AI 平台里的插件有一个区别。传统插件通常和特定的模型或者特定的 API 绑定换了模型插件可能就不能用了。OCTO 的技能是纯提示词层面的东西它描述的是能力逻辑而不是调用路径具体的模型调用由运行时自己去处理。一个 Agent 可以同时挂载多个技能组合出不同的能力矩阵。比如一个日常运维 Agent可以挂上邮件处理、日历管理、代码审查三个技能包每个技能包都是独立维护、独立迭代的。团队里有人写了一个好用的数据分析技能其他 Agent 直接挂上就行不需要为此切换运行时或者修改底层模型配置。OCTO 还支持从 Skills 市场和 MCP 市场导入技能这进一步降低了从零构建 Agent 能力的成本。市场里的技能经过格式标准化导入之后直接挂载到 Agent 上就能用不需要二次适配。对于技术团队来说内部沉淀的好技能也可以在团队内共享一个人踩过的坑、调过的 prompt变成了组织级别的可复用资产。六种协作模式解决的是 Agent 之间怎么配合的问题多 Agent 协作在 OCTO 里通过 Loop回路来组织。Loop 是一个任务容器规定了哪些 Agent 参与、以什么模式协作、任务的输入输出是什么。OCTO 提供了六种协作模式Solo 是单个 Agent 独立完成任务Roundtable 是多个 Agent 围绕同一个问题各自给出回答适合需要多视角输入的场景Critic 模式下一个 Agent 生成内容另一个负责审核和反馈Pipeline 是链式执行上一个 Agent 的输出作为下一个的输入Split 把一个大任务拆成子任务分发给不同 AgentSwarm 则是动态调度根据任务需要自动选择合适的 Agent。这六种模式的选择权在用户手里平台不做默认推荐。一个实际的使用场景是代码审查流程Pipeline 模式串联代码生成 Agent 和代码审核 Agent生成完自动送审审核不通过的修改意见回流给生成 Agent 重新修改。整个过程里两个 Agent 可以跑在完全不同的运行时上一个用 Claude Code 生成一个用 OpenClaw 审核Pipeline 只关心数据在 Loop 里的流转。智能体管理模块在这里起到了枢纽作用。每个 Agent 的指令system prompt、技能挂载列表、运行时绑定关系、运行统计数据都集中在这个模块里管理。当你要调整某个 Agent 的行为改它的指令或者换一组技能包就行不需要碰运行时的配置。运行统计数据也能帮你判断哪些 Agent 在哪些任务类型上效率更高这些信息会影响后续 Loop 的 Agent 选择。O.C.T.O. 四个字母背后的设计取舍OCTO 的全称拆开来是 Open、Context、Taste、Orchestration这四个词分别对应了架构设计里的四个取舍方向。Open 体现在运行时的开放接入不限定用户必须用哪家的模型或哪个 Agent 框架。Context 体现在 Workspace空间的设计上每个 Agent 在自己的空间里积累上下文、保存工作记忆任务之间的上下文可以跨 Loop 传递。Taste 对应的是 Preference经验系统Agent 的行为偏好和工作习惯可以随着使用不断沉淀这部分经验数据归用户所有。Orchestration 对应的是 Loop 的编排能力六种协作模式加上灵活的 Agent 组合让任务编排可以适应不同复杂度的工作流。私有部署是 OCTO 的默认交付方式。所有数据包括 Agent 配置、Workspace 内容、Loop 记录、Preference 数据全部存储在用户自己的环境里。平台层不碰用户的模型 API Key运行时在用户本地或用户指定的服务器上运行。这些设计加在一起我们想解决的问题其实很具体让团队在选择 AI 工具时不必在模型能力和平台锁定之间做取舍。OCTO 的源码在 GitHub 上开放。https://github.com/Mininglamp-OSS 一个 Agent 挂多个技能，多个运行时共存，OCTO 的架构怎么做到的
大多数 AI 平台的架构里模型调用和任务编排是绑死在一起的。你用某个平台的 Agent就只能调这个平台支持的模型用这个平台内置的工具链按照这个平台规定的流程走完一轮对话或一次任务。这带来一个很直接的问题当你想换一个模型运行时比如从云端 API 切到本地部署的 Ollama或者从 Claude Code 换成 Codex你大概率要在另一个平台上重建整套 Agent 配置。技能要重新挂身份要重新设上下文全部丢掉。OCTO 做架构设计的时候我们选了一条不同的路线把平台的职责收窄到两件事上身份管理和任务管理然后把模型调用和具体执行的部分完整地交给外部运行时。这篇文章拆解一下这个分层设计的具体逻辑以及它在技能挂载、Bot 接入、多 Agent 协作这几个场景下的实际效果。平台层只回答两个问题“是谁和做什么”OCTO 的平台层由四个模块组成IM 核心负责消息路由回路 ServerLoop Server管理任务生命周期智能层处理上下文拼装和策略分发Bot Framework 负责对接各种运行时的 Agent。在这四个模块里没有任何一个直接调用大模型 API。这个设计选择意味着平台层关心的是这个 Agent 叫什么名字、有什么能力标签、当前在哪个 Loop 里执行什么任务、任务进展到哪一步了。至于这个 Agent 底层跑的是 GPT-4o 还是 Qwen 还是本地的 Llama平台层完全不管。Agent 的身份信息通过 AgentCard名片来描述。一张 AgentCard 里标明了这个 Agent 具备的能力比如写代码、做数据分析、翻译、法务审核同时也挂载了它的技能包和运行时绑定关系。AgentCard 是平台层的东西它定义了 Agent 在 OCTO 生态里的身份但不限定这个 Agent 的底层实现方式。执行层独立出去之后运行时变成了可插拔的执行层在 OCTO 的架构里叫 OctoPush包含本地客户端和 Runtime 网关两部分。本地客户端跑在用户的机器上Runtime 网关负责管理运行时的注册、健康检查和状态同步。我们目前支持的运行时包括 OpenClaw、Claude Code、Codex、Hermes 等。每一种运行时都有自己的模型调用方式、自己的工具链、自己的 Agent 执行逻辑。OCTO 不去统一这些差异而是通过 Bot Framework 提供一个标准化的接入协议让任意运行时上跑的 Agent 都能以统一的身份出现在 OCTO 的 IM 和 Loop 里。一个开发团队可能同时在用 Claude Code 做代码生成、用 OpenClaw 跑日常运维任务、用一个自研的 Agent 做数据清洗这三个 Agent 分别在不同运行时上执行但在 OCTO 里它们都是有 AgentCard 的协作成员可以被拉进同一个 Loop参与同一个任务流。这种拆法还有一个不太显眼但比较实用的好处。运行时的健康管理和 Agent 的任务管理彻底分开了。一个运行时挂了或者需要升级不影响这个 Agent 在 Loop 里的任务状态重新绑定一个运行时就能接着跑。Runtime 网关会持续做健康检查和状态同步当某个运行时掉线的时候平台层只是把这个 Agent 标记为暂时不可用它的 AgentCard、已有的技能挂载、在 Loop 中的任务记录全部保留。等运行时恢复或者换了一个新的运行时注册上来绑定关系一更新任务继续推进。这和传统 AI 平台的做法形成了比较明显的对比。传统方案里模型挂了往往意味着整条链路中断因为任务编排逻辑、上下文管理、工具调用全部依赖同一个模型服务端点。OCTO 把这些依赖关系拆散了平台层的稳定性和运行时的稳定性互不影响。技能系统让 Agent 的能力变成可以拼装的零件OCTO 里的技能Skill是一种可复用的提示词包你可以把它理解成一段经过调试和验证的 system prompt 加上配套的工具调用说明打包成一个独立的单元挂到任意 Agent 上。技能的设计逻辑和传统 AI 平台里的插件有一个区别。传统插件通常和特定的模型或者特定的 API 绑定换了模型插件可能就不能用了。OCTO 的技能是纯提示词层面的东西它描述的是能力逻辑而不是调用路径具体的模型调用由运行时自己去处理。一个 Agent 可以同时挂载多个技能组合出不同的能力矩阵。比如一个日常运维 Agent可以挂上邮件处理、日历管理、代码审查三个技能包每个技能包都是独立维护、独立迭代的。团队里有人写了一个好用的数据分析技能其他 Agent 直接挂上就行不需要为此切换运行时或者修改底层模型配置。OCTO 还支持从 Skills 市场和 MCP 市场导入技能这进一步降低了从零构建 Agent 能力的成本。市场里的技能经过格式标准化导入之后直接挂载到 Agent 上就能用不需要二次适配。对于技术团队来说内部沉淀的好技能也可以在团队内共享一个人踩过的坑、调过的 prompt变成了组织级别的可复用资产。六种协作模式解决的是 Agent 之间怎么配合的问题多 Agent 协作在 OCTO 里通过 Loop回路来组织。Loop 是一个任务容器规定了哪些 Agent 参与、以什么模式协作、任务的输入输出是什么。OCTO 提供了六种协作模式Solo 是单个 Agent 独立完成任务Roundtable 是多个 Agent 围绕同一个问题各自给出回答适合需要多视角输入的场景Critic 模式下一个 Agent 生成内容另一个负责审核和反馈Pipeline 是链式执行上一个 Agent 的输出作为下一个的输入Split 把一个大任务拆成子任务分发给不同 AgentSwarm 则是动态调度根据任务需要自动选择合适的 Agent。这六种模式的选择权在用户手里平台不做默认推荐。一个实际的使用场景是代码审查流程Pipeline 模式串联代码生成 Agent 和代码审核 Agent生成完自动送审审核不通过的修改意见回流给生成 Agent 重新修改。整个过程里两个 Agent 可以跑在完全不同的运行时上一个用 Claude Code 生成一个用 OpenClaw 审核Pipeline 只关心数据在 Loop 里的流转。智能体管理模块在这里起到了枢纽作用。每个 Agent 的指令system prompt、技能挂载列表、运行时绑定关系、运行统计数据都集中在这个模块里管理。当你要调整某个 Agent 的行为改它的指令或者换一组技能包就行不需要碰运行时的配置。运行统计数据也能帮你判断哪些 Agent 在哪些任务类型上效率更高这些信息会影响后续 Loop 的 Agent 选择。O.C.T.O. 四个字母背后的设计取舍OCTO 的全称拆开来是 Open、Context、Taste、Orchestration这四个词分别对应了架构设计里的四个取舍方向。Open 体现在运行时的开放接入不限定用户必须用哪家的模型或哪个 Agent 框架。Context 体现在 Workspace空间的设计上每个 Agent 在自己的空间里积累上下文、保存工作记忆任务之间的上下文可以跨 Loop 传递。Taste 对应的是 Preference经验系统Agent 的行为偏好和工作习惯可以随着使用不断沉淀这部分经验数据归用户所有。Orchestration 对应的是 Loop 的编排能力六种协作模式加上灵活的 Agent 组合让任务编排可以适应不同复杂度的工作流。私有部署是 OCTO 的默认交付方式。所有数据包括 Agent 配置、Workspace 内容、Loop 记录、Preference 数据全部存储在用户自己的环境里。平台层不碰用户的模型 API Key运行时在用户本地或用户指定的服务器上运行。这些设计加在一起我们想解决的问题其实很具体让团队在选择 AI 工具时不必在模型能力和平台锁定之间做取舍。OCTO 的源码在 GitHub 上开放。https://github.com/Mininglamp-OSS