管住了Agent的状态，谁来管Agent的能力？
2026年6月，清华大学Rath Team在PyPI上发布了OpenRath v1.2.1——一个被他们描述为"像PyTorch的多智能体、多会话运行时"。InfoQ随即刊发了一篇深度解读，标题直击痛点：《上百个Agent，该怎么管？》
这篇文章在技术圈引发关注的原因并不复杂。几乎每个把Agent系统真正跑大的团队，最终都会撞上同一堵墙：Agent数量一上来，状态就乱。一个Agent维护一份上下文，另一个Agent又复制一份历史；一个任务分叉出好几条推理路径，最后没人说得清哪条分支产出了最终答案。Demo跑得挺好，一到几十上百个Agent，调试、复现、编排全部失控。
OpenRath给出的解法朴素到近乎反直觉：别再围着Agent转了，真正该被当成一等公民的，是Session。
一、OpenRath的启示：状态治理是一门"基础设施"级的工程
OpenRath的核心设计借了PyTorch的三样东西，一一映射到Agent系统上。Tensor对应Session——流动的数据不是聊天记录，而是结构化的证据链。Layer对应Agent——Agent只是Session上的一层变换，吃进一个Session、吐出一个Session，不持有状态。Device对应Sandbox和Memory——工具在哪执行、记忆存在哪，全部做成可插拔的后端，与业务逻辑解耦。而整张Session Graph，是跑起来才长出来的动态图，支持fork分叉、detach切断血缘、merge合并。
这三根支柱解决了一个根本问题：当Agent集群规模膨胀，谁拥有这份工作的状态？ OpenRath的答案是让Session成为路由的单位，让Session Graph成为控制平面——Agent、工具、工作流、记忆、沙箱位置，全网在这张图上交汇。用他们的话说：“Agent是工人，Session才是工作本身。”
这无疑是一次重要的工程升维。但顺着这条线索往下追问，一个同样关键的盲区会浮现出来：Agent在Session上干活时，它用的是什么能力？这些能力从哪来、按什么标准保证质量、由谁统一管理？
OpenRath管住了Agent运行时的状态。但Agent的能力本身——那些让它知道"什么时候该做什么、怎么做、做完怎么验证"的Skill——同样需要一套治理体系。后者，恰恰是当前Agent工程讨论中相对沉默的另一半。
二、Skill不是Prompt的新马甲
要理解这个问题，先得澄清一个普遍的误解：Skill不是"更长的系统提示"。
2026年，“Skill"几乎成了Agent工程领域被讨论最多的词。每个主流平台都在推自己的Skill目录结构，每个技术团队都在把经验沉淀成Skill。但一个尴尬的现实是：大部分Skill写出来之后，Agent的表现并没有变好，有时甚至变得更差。根因在于，很多人把Skill当成了"按固定格式写成的说明书”——如果只是这样，那它和在系统提示里多塞几段规则没有本质区别。
一个真正的Skill，在结构上至少要串联四层。指令层描述"什么时候触发、按什么步骤做"，决定Agent在什么场景下激活这个能力。知识层提供"做的时候依据什么"，把散落在团队文档和隐性经验中的知识结构化为Agent可加载的上下文。执行层负责"做完了怎么验证"，将可机械化的检查从Agent的推理链路中剥离，用确定性代码替代概率性判断。评测层回答"这个Skill到底有没有用"——每个测试用例跑两遍，一遍带Skill、一遍不带，用数据说话。
这四层不是平铺的清单，而是一条串联链路：指令层决定触发→知识层提供上下文→执行层做确定性校验→评测层闭合反馈。缺任何一层，Skill就从"工程资产"退化为"一段增强提示词"。
Google ADK团队提出的五种Skill设计模式——Tool Wrapper、Generator、Reviewer、Inversion、Pipeline——表面上是一套分类法，底层揭示的是一个更深的事实：Skill的类型，应该由它要解决的根本问题决定，而不是由你手头有什么知识决定。Tool Wrapper解决"知道什么"——让Agent按需成为某个工具或领域的临时专家；Generator解决"输出长什么样"——用模板保证结构稳定；Reviewer解决"按什么标准判断好坏"——把评审流程和评审标准分离；Inversion解决"信息不足时先问什么"——防止Agent在模糊需求上过早自信；Pipeline解决"复杂流程如何不跳步"——用检查点强制顺序。你会发现，这五个问题没有一个是在问"这段知识怎么写"，它们问的全是工程问题：稳定性、边界、标准、交互控制、流程保证。写出好Skill的起点，不是打开编辑器写SKILL.md，而是先问三个问题：它解决的根本问题是什么？它和模型现有能力的差距在哪？用什么证据证明它确实填上了这个差距？
三、从"写Skill"到"管Skill"：技能仓库的必然性
理解了单个Skill怎么算写好，下一个问题自然浮现：当组织里的Skill从十几个膨胀到几十上百个，谁来管？
这个问题的紧迫性，API7.ai创始人温铭在最近一篇InfoQ文章中给出了一个侧面印证。他烧掉了几百亿Token用AI从零重写了生产级网关AISIX，并总结出一条核心经验：AI的能力早就溢出了，跟不上的是人。 AI看得懂What、能完成How，但Why——那些藏在资深工程师脑子里的架构决策、概念抽象、异常判断——从来没有被很好地写进任何公开知识库。他给自己定了一条原则：“这个决定你要是看不懂，那就一定别做。”
这里恰好藏着Skill管理的核心命题：怎么把"人脑子里的那张图"——那些Why——结构化为Agent可以加载、可以执行、可以被验证的工程资产？ 而这，就是技能仓库要回答的问题。
在Agent Skill Warehouse的实践中，这个命题被拆解成了三个维度。结构串联——BA-Master、SA-Master、PM-Master三个核心Skillset，各自都有从指令到知识到执行到评测的完整链路，而不是一堆文件的松散集合。以SA-Master为例：指令层定义"在需求规格确认后触发"，知识层加载架构规范、技术选型矩阵和安全合规清单，执行层做接口契约校验和依赖冲突检测，评测层用对照测试验证架构建议的准确率。资产管理——每个Skill有版本号、变更日志、兼容性声明和可评测的通过率数据，让"这个Skill值不值得引入"成为一个数据驱动而非拍脑袋的决策。运行保障——权限策略由平台统一执行而非在每个Agent的Prompt里手写访问控制规则，执行轨迹被记录并可回溯到具体的Agent和人类操作者。
三个Skillset的分工恰好对应了企业从概念到交付的完整跨度：BA-Master锁定业务范围——根目的澄清→需求结构化→异常分支穷举；SA-Master框定技术边界——七维度架构确认，覆盖性能、安全、合规、可维护性等关键面；PM-Master做跨角色编排——把BA的输出和SA的约束组织成可执行的交付计划。但更值得关注的是它们背后的共性：每一个Skillset都把"文档"从给人看的辅助材料，变成了给Agent执行的上下文约束。 温铭说的"脑子里的图"，正是通过这种结构化，从个人经验变成可复用、可迭代的工程资产。
四、两块拼图，一个方向
OpenRath管住了Agent运行时的状态——Session从聊天记录升级为证据链，让集群可观测、可追溯、可回滚。Agent Skill Warehouse管住了Agent的能力——Skill从"某人写了一段好用的提示词"升级为"组织可复用的工程资产"，让能力可发现、可评测、可治理。
两块拼图缺一个，企业AI基础设施就不完整。有状态治理没能力治理，你知道Agent每一步做了什么，但不知道它是从哪学会做这些事的、这些能力经过了什么质量验证。有能力治理没状态治理，你知道每个Skill的边界在哪，但不知道是谁、在什么上下文中触发了它、执行过程是否越界。
OpenRath的团队说了一句意味深长的话：从Prompt工程走向系统工程。这句话的完整版本应该是：不仅要管住运行时的状态流动，还要管住能力资产的全生命周期。技能仓库，就是这张拼图上缺了很久的那一块。
参考资料：
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
3
0- 0
已为社区贡献4条内容
所有评论(0)