上周豆包对智能体广场做了一轮清理，一批自定义Agent被下架或降低分发权重，几乎同一时间千问也收紧了智能体的创建权限和分发规则。两条消息在开发者圈子里没引起太大讨论，类似的事情发生过太多次，多少有些麻木了，但这次被波及的群体比以往几次都痛，因为现在搭在大模型平台上的已经不只是聊天bot，而是真正承载业务流程的Agent，花了大量时间调prompt、接工具、积累用户和使用数据，说没就没了。
整个互联网平台经济的历史几乎就是一部第三方开发者被过河拆桥的历史。Twitter把API从免费改成高价收费那天一整个生态的第三方客户端直接消失，OpenAI上线GPTs时开发者蜂拥而入，几个月后大部分GPTs连自然流量都拿不到，做了等于没做，Slack、Notion、Discord的bot生态都重复过同一个剧本：平台早期需要开发者填充生态、贡献内容、帮忙验证产品方向，敲锣打鼓把人请进来，等用户行为数据收够了、核心场景摸清楚了，要么把热门功能做成原生内置，要么修改接口规则提高第三方的生存成本，要么在分发上掐断流量入口。商业公司做产品调整本来无可非议，股东利益优先于开发者生态是常态，没有哪家上市公司有义务为第三方开发者的业务连续性兜底，但每次轮到开发者自己踩这个坑的时候，还是能看到很多人直到关停通知出来才意识到问题。
在云端Agent这件事上风险其实比传统SaaS高一个量级，传统SaaS服务停了数据还能导出，换一个同类工具迁移成本虽然有但不至于伤筋动骨，Agent产品不一样，开发者沉淀在平台上的东西远不只是结构化数据，还有整套prompt工程的调试结果、工具调用链的编排逻辑、function calling的参数格式适配、跟平台模型版本深度耦合的上下文管理策略，这些东西不是一个导出按钮能搬走的，平台一旦改了模型版本或者下线了某个接口，整套体系可能要从头来过。行业里已经有不少团队踩过这个坑，核心产品就是一个基于某家大模型API搭建的垂直Agent，模型一次大版本升级导致prompt体系大面积失效，而他们连模型版本都锁不住。
这几年对本地部署和端侧推理的讨论越来越多，背后就是这层顾虑，模型权重在本地、推理在自己的硬件上跑、代码在自己的仓库里，不存在被远程关停的可能，模型什么时候升级、API怎么设计、数据往哪走全部自己决定。我们在做Mano-P的时候从第一天就把全本地运行当作硬性前提，GUI Agent的截图数据和操作指令完全不离开用户自己的设备，4B量化模型在M4 Pro的Mac上可以跑到76 tokens/s的decode速度，峰值内存占用4.3GB，不需要目标应用开放任何API，纯视觉理解屏幕内容然后直接操作，这条路在技术上比调云端API难得多，但是一旦跑通用户拿到的东西真正是自己的。
端侧解决了执行层的主权问题，但Agent在真实工作场景中落地时遇到的挑战远不止推理在哪跑这一件事。稍微复杂一点的业务流程都涉及多个Agent之间的分工协作，需要有人盯着任务的执行进度和中间状态，需要把人和Agent之间反复沟通、验收、打回的过程记录下来便于追溯，还需要让Agent记住团队的工作习惯和偏好，不然每次换了人或者换了模型都要从头教起，这些执行层的问题在现有的云端Agent平台上基本被忽略了，大部分平台提供的本质上还是一个prompt加一个工具调用框架，Agent之间怎么编排、任务状态怎么追踪、人和Agent怎么协作验收、团队知识怎么沉淀，全靠开发者自己搭。
我们在这个方向上做了一个开源工作台叫Octo，代码已经在GitHub上开放。Octo的设计从一开始就没有绑定任何一家AI厂商，接入层支持OpenClaw、Claude Code、Codex、Hermes等多种运行时，也可以接入任何自己部署的开源模型，切换模型不影响已经建好的工作流和沉淀下来的偏好数据，部署方式完全自主，可以放在自己的基础设施上跑，业务数据和协作记录留在自己手里。
Octo的任务管理单元叫回路Loop，跟传统工单系统不太一样，回路是从日常对话中自然生长出来的，不需要先填表再干活，用一句话说清楚要做什么，指定一个智能体作为负责人，回路就建好了，智能体接到任务后自动开始执行，产出物直接挂在回路上等待验收，发起人审核通过就关单，不满意就打回修改，每一次打回时批注的修改意见都会被记录为Preference经验条目，同一个智能体下次接类似任务时会自动参考历史经验，用得越多越懂团队的做事标准和审美偏好。
这里面有一个很关键的设计选择是Preference经验系统，这是Octo跟其他协作平台差异比较大的地方。每次验收、打回、批注"我更喜欢这样"的时候，系统不是简单地把反馈停留在这一次任务的评论区里，而是把它提炼成一条可复用的经验条目，挂在对应智能体的经验库里。下次这个智能体接到类似任务，在执行阶段就会自动检索相关的历史经验作为上下文参考。一个写文档的智能体如果反复被打回过"段落不要用总分结构""段首不要放总结句"这类批注，它下次写的时候就会自动避开这些写法，不需要人再重复说一遍。这个能力的价值在于团队的偏好和做事标准不会因为人员变动或者模型切换而丢失，核心成员离职了知识不走，底层模型升级了偏好数据还在。
协作编排方面Octo内置了六种模式覆盖不同的工作场景。Solo模式处理简单的单智能体任务，Roundtable模式让多个智能体在同一上下文里自由讨论适合头脑风暴和多角度分析，Critic模式下做任务的智能体和审任务的智能体互相看不到对方身份，避免先入为主的判断影响审核质量，Pipeline模式按顺序流转上一步的输出作为下一步的输入，Split模式把一个任务拆开分给多个智能体各自独立完成再合并结果，Swarm模式让多个智能体同时解同一个问题最后挑选质量最好的那份交付。这些编排逻辑不是普通聊天窗口能承载的，群聊的设计前提是所有人看到所有消息，而实际协作中经常需要控制信息的可见范围，审核者不应该提前知道是谁做的，并行任务的参与者之间不应该互相干扰。
除了任务编排和经验沉淀，Octo还有一整套执行层的基础设施在支撑整个协作流程。回路工作台提供列表和看板两种视图，统一工具条可以在任何回路页面快速切换上下文，子任务树支持把大任务拆成多层级的子任务分派给不同智能体，迭代记录保留每一次修改和打回的完整历史，评审打回流程有明确的状态流转，计划图可视化可以看到整个任务的时间线和依赖关系。项目分组功能可以把相关的回路归堆管理，挂成员和智能体作为项目常驻资源。自动化流水线支持定时触发和事件触发两种模式，可以配置目标、上下文、步骤runbook和输出模式，实现比如"每天早上9点让数据智能体跑一遍昨日数据汇总发到群里"这类固定流程。跨回路和跨项目的搜索已经上线，可以快速检索历史任务和产出物。
智能体管理模块正在V1开发阶段，包括指令配置、技能挂载、运行时绑定和运行统计，上线后可以在一个地方管理团队所有智能体的配置和健康状态。运行时注册与健康检查也在开发中，第一版支持自带机器，智能体跑在自己的CLI daemon上，平台负责注册、监控状态和分发任务。工作区组队功能允许从空间通讯录自由拉人或拉智能体组队，回路从工作区继承常驻资源不用每次重新配置。技能市场和A2A智能路由在规划中，技能市场允许把可复用的提示词包和做事方法封装成技能在组织内共享甚至跨组织分发，A2A路由让领队智能体感知其他智能体的专长自动把子任务路由给最合适的执行者，这两个能力会在执行闭环跑顺之后再推进。
四个端的覆盖也在同步推进，Web和桌面端提供完整的协作工作台，移动端主要处理通知、快速回复和验收智能体产出，浏览器插件可以在任何网页旁呼出Octo自动带入页面上下文，CLI是智能体原生的操作方式，通过命令行接收任务和提交产出，IM端保持团队熟悉的群聊界面，@一句就能起一件事。
端侧推理解决的是Agent执行能力的主权问题，开源协作工作台解决的是Agent之间、人和Agent之间的协作问题，这两个方向合在一起指向同一个趋势，Octo整个平台的设计围绕一个基本判断：开发者对工具链的控制权比功能丰富度更重要。云端平台会继续迭代和调整，API不会永远稳定，把核心工作流架构在自己能掌控的基础设施上，比等待任何一家平台的政策连续性靠谱。
Octo目前回路工作台、项目分组、自动化流水线、跨项目搜索都已经可用，智能体管理和运行时注册本月内陆续开放，代码和部署文档都在GitHub上。https://github.com/Mininglamp-OSS/octo-web
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
