一、从一个公式说起：Agent = Model + Harness

过去两年，业界把大量精力投在"让模型更聪明"上：更好的提示词、更长的上下文窗口、更强的基座能力。但真正把一个Agent放到长周期、多环节的真实任务里跑，你会发现模型再聪明也不够用——它常常在第三步忘了第一步的目标，工具报错后不知所措，碰到权限边界还会横冲直撞。

JiuwenSwarm给出的答案：

Agent = Model + Harness

模型（Model）提供"大脑"，也就是推理与决策的能力。Harness（驾驭层）提供"躯干和四肢"，负责把一个"可对话的推理单元"驾驭成一个能规划、能调用工具、能管理上下文、能受权限约束、能委派子任务、能持续演进的任务执行系统。

Harness关注的不是替代模型，而是补齐模型外部的执行、状态、约束和反馈机制。 模型负责生成推理和行动意图，Harness负责把这些意图放进一个受控的工程执行系统里落地。文档把这件事称为 Harness Engineering（驾驭工程）— 构建模型之外的工程化执行环境，由这个环境去管理任务循环、工具、上下文、状态、权限、记忆、验证、停止条件和反馈回路。

换句话说，模型决定了Agent能力的上限，而 Harness 决定了Agent在真实世界里实际能跑出多少分。JiuwenSwarm的工程价值，几乎都建立在"把Harness这件事做扎实"之上。

二、openJiuwen Harness是怎么搭起来的

openJiuwen Harness的总体架构由三层组成：

2.1 DeepAgent Core Engine（核心引擎）

DeepAgent是整个Harness的运行时主体。它在内部复用了经典的ReAct推理循环（Think → Act → Observe），并在外层包了一圈能力：任务管理、状态管理、Rail生命周期、子代理委派。

DeepAgent有两种运行形态，对应两类不同的任务：

• • 单轮ReAct模式：适合短任务和直接工具调用，开销低、响应快；
• • 双层Task Loop模式：适合长程任务，支持多轮推进，以及运行中的follow_up（补充提问）、steer（运行时引导）、abort（中断取消）三类交互。

外层的Task Loop由TaskLoopController、LoopCoordinator等组件构成，每一轮任务提交为一个CoreTask，执行完再评估停止条件决定是否进入下一轮。后面所有"长周期任务可控"的能力，地基都在这套双层循环上。

2.2 Extension（扩展层）

四类扩展面，各自对应Agent能力的一个维度：

• • Subagent：把复杂任务委派给子代理，并隔离子代理的上下文——比如代码审查时启动一个只读的 verification_agent 独立验证，结果返回到主 Agent；
• • Tool：工具系统覆盖文件操作、Shell与代码执行、Web搜索与抓取、图像OCR与视觉问答、LSP代码智能（定义跳转、引用查找、调用层级、诊断）、MCP外部资源接入、定时任务等十几个能力族；
• • Rails：生命周期钩子机制，下文详述，这是Harness最具特色的设计；
• • Stop-Condition：最大轮数、超时、Token预算、完成承诺、自定义谓词，OR语义任意一条满足即停止。

2.3 Infrastructure（基础设施层）

系统操作抽象（统一的文件/Shell/代码执行接口，收敛本地执行、沙箱、工作目录限制于一处）、会话管理（状态持久化、中断恢复、分支会话）、权限控制（tiered_policy 分层策略）。

2.4 Rail：贯穿全系列的"生命周期钩子"

三层架构之外，有一个机制值得单独拎出来讲，因为它几乎在JiuwenSwarm的每一个能力模块里都会出现：Rail（生命周期扩展机制）。

Rail不替换主流程，而是在"外层任务""内层模型调用""工具调用"这些关键节点上注入能力。它提供的钩子包括：

Rail的意义可以这样理解：任务规划、上下文压缩、记忆注入、技能演进、权限拦截、安全防护，这些看起来彼此独立的能力，说到底都是挂在DeepAgent生命周期不同钩子上的一条条Rail。 比如TaskPlanningRail挂规划能力、ContextProcessorRail挂上下文压缩、EvolutionRail挂技能演进、PermissionInterruptRail挂权限拦截。模式系统切换运行档位，做的其实就是"挂载"或"卸载"不同的Rail组合。

这个机制贯穿了JiuwenSwarm几乎每一个能力模块。

三、「蜂群」的隐喻：从一只到一群

JiuwenSwarm的名字里有个「Swarm（蜂群）」。这不只是好听的代号，它指向框架的第二层野心：当单个Agent足够强之后，怎么让一群Agent协同起来。

单个智能体难以兼顾多环节任务，串行执行效率低，复杂任务容易出错，也难以持续优化。全屋装修要硬装设计师、软装设计师、艺术顾问各司其职；200页技术报告需要10个方向的专家并行调研；医疗会诊需要23位不同专科的AI专家联合研判。

于是有了Agent Team（集群模式），让多个专业化的Agent像蜂群一样围绕同一个目标分工协作。这个隐喻落地成了一种「分级自主协同」结构：

• • Leader Agent（蜂群统筹）：负责目标理解、动态团队组建（根据任务特征按需选取成员，不需要预配置）、任务规划与依赖识别、关键决策审批、整体推进和结果汇总；
• • Teammate Agent（专业执行）：负责认领自己擅长的任务、在自己的独立工作空间中执行、必要时求助协调、汇报进度、提交产物。

它既不是"全靠人工编排"的死板流水线（用户不需要手动指定每个Agent的执行顺序），也不是"完全放养"的无治理乱局（Leader统筹协调）。Leader统筹大局，Teammate自主认领专长任务。 这正是真实蜂群的运作方式：有统一目标，有分工，每只蜜蜂又在自己的岗位上自主行动。

协同由事件驱动机制推动：任务状态变更、成员通信、成员异常等事件在事件总线上流转。Teammate卡住了，Leader自动收到事件决定重试还是换人。空闲Teammate主动认领待领任务。同时，全生命周期管控确保关键决策和敏感操作需经Leader审批；成员异常僵死、任务无人认领等单点问题在可控时间内被发现并处理。

这件事的本质，是从Harness Engineering（驾驭工程）走向Coordination Engineering（协同工程）：从琢磨"怎么让单个Agent更强"，变成琢磨"怎么让一群Agent好好协作"。Agent Team的核心不是『更强的Agent』，而是『更好的协作』。

四、四大核心组件：从协作到进化

JiuwenSwarm在蜂群协同之外，构建了三大支柱让协作经验不丢失、能共享、会进化，与Agent Swarm构成完整闭环。

4.1 Agent Swarm：协同内核

第三节讲了分级自主协同、事件驱动、全生命周期管控的基本框架。这里补充几个支撑这套机制运转的关键设计。

共享工作区（Team Workspace）。每个成员有自己的私有空间（记忆、技能、待办），团队有一个共享产出区。三个设计要点：（1）私有空间互不污染，每个人的上下文只属于自己；（2）文件级锁定，有人在写报告时，其他人只能读，不会冲突；（3）前置产出自动成为后续输入，调研Agent把数据放进共享区，分析Agent直接拿来用，不用Leader在中间传文件。

事件驱动 + 断点续执。协同不是靠Leader轮询"你做完了吗"。任务状态变更、成员通信、成员异常等事件在事件总线上流转。Teammate卡住了，Leader自动收到事件决定重试还是换人。空闲Teammate主动认领待领任务。团队状态通过SQLite检查点数据库持久化，中断后可从最近检查点恢复而非从头再来。

智能模型路由（Model Routing）。不同角色对模型能力的要求完全不同，Leader做复杂推理走强模型，调研Teammate大量搜索阅读走性价比模型，代码Teammate需要精确推理走代码专项模型。路由规则可配置，团队组建时Leader根据任务特征自动匹配。PinchBench评测中Token消耗降了34.8%，主要贡献就在这里。

全生命周期管控。关键决策和敏感操作需经Leader审批，遵循"Agent可自主建议，决策权在Leader"的原则。同时有多重事故防护：Teammate超时无人认领 → Leader识别并重新规划或换人；已认领任务迟迟不完成 → Leader评估是否需要介入；成员异常僵死 → 事件总线自动触发告警。任何单点问题都能在可控时间内被发现并处理，不会阻塞整个团队。

4.2 Swarm Skills：团队级技能包

Agent Swarm解决的是"当下怎么协作"。但会话结束后，经验全丢。Leader怎么拆解任务的、团队需要几个什么角色、谁先谁后、协作流程怎么走的 —— 全部消失。下次遇到同类任务，一切从零开始。

Swarm Skills正是为解决这个"会遗忘"的问题而设计的。它把一次成功协作的全链路，需求拆解、团队组建、任务分配、通信机制、冲突处理、交付规范封装为标准化的团队技能。

一个Swarm Skill就是一个目录：SKILL.md定义团队干什么、成员有谁；roles/定义每个角色职责；workflow.md定义协作流程和时序；bind.md定义边界和异常规则。简单任务两三个文件就够，复杂任务按需补充，几乎没有门槛。

创建团队技能不需要手写。JiuwenSwarm内置了SwarmSkill Creator，输入一句自然语言即可自动生成完整的Team Skill，自动检索已有skill和工具装配给对应成员，本地没有的还能从技能市场（SkillNet、ClawHub）自动检索合适的外部skill。生成的技能跨框架兼容，在Claude Code、Cursor等支持Agent Skills标准的平台上可以零适配运行。

一个实际案例：输入"帮我创建一个医疗专家会诊的团队技能，要求科目齐全，能根据病情描述按需加载"，SwarmSkill Creator自动生成了具备 23位AI医学专科专家的完整团队技能。该技能可根据病情动态创建多个不同专科专家团并行会诊，整个过程从专家如何被选中创建、哪些环节已完成、谁在并行工作、下一步由谁接力，完全可见、可追踪。

4.3 Swarm Skills Hub：共享技能市场

技能沉淀下来了，怎么共享？

Swarm Skills Hub就是答案。它是一个开放平台，已内置开发编程、办公生产力、内容创作、多模态与媒体、数据与科研、合规与法律、生活与健康、金融与理财八大类别的开箱即用技能。开发者可以上传自己跑通的Swarm Skills，也可以下载别人验证过的团队协作方案直接使用或二次开发。

Hub提供了完整的协作工作流：创作者上传Skill → 审核管理员审核 → 普通用户浏览、下载、使用。同时内置版本管理，技能更新后发布新版本，使用者可选择升级或继续使用旧版本。CLI工具支持自动化对接。

除了官方托管，也支持自建实例部署，团队可以在自己的服务器上部署Hub，功能与官方托管一致，登录提供商和审核员名单由实例管理员在.env中配置。本质上，Hub把"团队协作经验"做成了一个可交易、可复用、可评分的市场。一个团队在医疗会诊场景跑通的协作经验，另一个团队可以直接下载复用，不用从零摸索。

4.4 Swarm Skills自演进：越用越强

能复用还不够。真正的团队需要在每一次实战中自我迭代。

怎么发现"需要改进"？ JiuwenSwarm内置了 SignalDetector（信号检测器），持续监听对话和执行过程中的异常。它基于规则工作（不调LLM，响应快），识别两类信号：执行异常（工具超时、接口报错、代码中断）和用户纠错（"不对""应该换个方式""你理解错了"）。用户纠错往往比异常日志更有价值，异常只告诉你"出错了"，纠错告诉你"哪里理解错了"。

检测到信号后做什么？ 信号归因到具体Skill，调LLM生成改进建议，写入Skill目录下的 evolutions.json，标记为"待固化"。用户审批通过后合并到 SKILL.md。异常案例 → 排障建议（写入Troubleshooting），纠错交互 → 正确用法示例（写入Examples）。演进不会静默落盘，方案弹出审批，确认后才写入。

演进在两个层面同时展开：

• • 团队技能层：系统根据执行轨迹自主演进Team Skills，增加成员角色、补充约束规则、优化协作流程；
• • 成员技能层：每位成员的Skill单独自主进化，工具报错、接口超时等实战经验自动沉淀。

演进采用补丁架构：经验以独立条目附加到Skills 上，不直接修改原始文件。每条经验携带触发来源、上下文、时间戳与质量评分，可单独审查与淘汰。就像人类团队里"经验手册"和"操作规程"分开管理，规程是基础，经验是补充，互不干扰。

触发方式有两种：开启自动扫描后，每次工具执行和对话结束系统自动检测信号，演进变成静默的"背景进程"；也可以手动触发，直接告诉系统"这个 Skill 需要改进什么"。经验积攒多了之后，可以按评分查看经验库、让系统整理去重、或一键将经验重组织回技能文档。

五、三种部署形态：从单机到分布式

JiuwenSwarm在工程落地上提供了从轻到重的三档选择，覆盖了从个人开发到企业级协同的完整需求。

单机模式，一行命令跑起来：这是大多数个人开发者的入口。初始化、启动、Web前端、Gateway网关，一条命令全拉起来，开浏览器就能用。所有数据存在本地用户目录下，适合上手、开发和轻量使用。

单机多实例，隔离互不干扰：一台机器上跑多个相互独立的JiuwenSwarm服务时，声明式定义每个实例的名称即可，系统自动分配独立的工作区、配置和错开的端口，互不冲突。适合开发调试或多项目并行，不用反复改配置重启。

分布式 Team，跨节点蜂群协同：单机受限于CPU、内存和网络，当团队成员需要浏览器环境、GPU推理或内网部署时就不够了。分布式模式让Leader和Teammate运行在不同机器上，精髓在于控制面与数据面分离，Teammate启动后向注册中心登记为"空闲节点"，Leader按需查询并预约，通过点对点通道完成引导接入，整个过程不需要提前知道任何Teammate的地址；任务分配、进度同步和消息传递走共享数据库，跨机器的文件通过共享存储即时可见。

"单机可跑、分布式可扩"，三档模式用同一套入口，按配置切换，不做分叉。这对从demo阶段过渡到生产阶段的团队来说，省掉的不是开发时间，更关键的是过程中不用换技术方案。

六、评测验证与多通道落地

评测成绩

JiuwenSwarm在PinchBench综合评测中取得94.2%的成绩，比OpenClaw高近 3 个百分点，同时Token消耗降低 34.8%。在LOCOMO长期对话记忆测试中，用 8B 模型即实现 85% 准确率。

Token消耗降了 34.8%，主要来自智能模型路由（Model Routing）：代码审查用强推理模型，资讯爬取用轻量模型，不同角色配不同级别的模型。

实战案例覆盖多个领域

• • 全屋装修：Leader组建硬装设计师、软装设计师、艺术家三个角色，从毛坯房到全装修全流程自动化。
• • 多学科医疗会诊：基于Team Skill创建 23 位不同专科的AI专家团队，分诊 → 并行分析→汇总输出完整会诊报告。
• • 智慧政务 12345 热线：Leader自动解析投诉诉求→动态组建城管、环保、住建联合处置团队 → 并行制定处置方案 → Leader 审批汇总，重构了"接诉即办"的底层协同逻辑。
• • 昇腾算子开发：TUI模式下算法设计/Kernel 实现/性能优化多角色协同编码。

人机协同双模式

JiuwenSwarm定义了两种人与Agent团队的交互模式：

• • HOTS（Human on the Swarm）：人站在蜂群之上当指挥，全局调度、调整优先级。
• • HITS（Human in the Swarm）：人以平等成员身份参与蜂群，和其他Agent同流程协作。

多通道与生态

配套了：

• 12 个通道：Web、CLI/TUI、飞书、钉钉、企业微信、鸿蒙小艺、Discord、WhatsApp、Telegram、Slack、邮件、Webhook
  

• 5种运行模式：agent.plan规划、agent.fast快速、code.normal编码、code.team编码团队、team集群
  

• SwarmFlow可控工作流编排："编排归系统，智能归 Agent"，支持 parallel/pipeline 等并发模式 + TUI 三层可视化监控。

华为云 AgentArts 已将 openJiuwen 引入商业化平台能力中，开箱即用。

七、小结：JiuwenSwarm是一台"驾驭引擎"

回到开头那个公式Agent = Model + Harness，可以把JiuwenSwarm的全貌总结成三句话：

1. 1. 底座是Harness。 用三层架构（核心引擎/扩展/基础设施）和Rail生命周期钩子机制，把模型驾驭成一个可控、可靠、可扩展的任务执行系统。
2. 2. 进阶是Swarm。 用Leader + Teammate的分级自主协同，把一只强大的Agent扩展成一群分工协作的蜂群：从"单兵作战"走向"蜂群协同"。
3. 3. 闭环是生态。 用Swarm Skills（经验沉淀）+ Swarm Skills Hub（技能共享）+ 自演进（持续进化）+ SwarmFlow（可控编排），让协作能力不丢失、能复用、会进化。

JiuwenSwarm想做的不是又一个更聪明的模型包装，而是一台能把模型能力稳定、安全、持续地兑现成真实生产力的「驾驭引擎」。

更多JiuwenSwarm信息，请参见官网：

• 官网地址：https://www.openjiuwen.com/

• AtomGit: https://atomgit.com/openJiuwen

PS：

更多Agentic AI技术前沿分享，欢迎扫描下方二维码进入技术交流群（或者添加群助手ID：qstarsky 邀请您进群交流）

Agentic AI

立即扫码

参考资料

1. 1. 官网地址：https://www.openjiuwen.com/
2. 2. AtomGit: https://atomgit.com/openJiuwen
3. 3. openJiuwen官方文档：

   https://openjiuwen.com/docs-page?path=%E4%BA%A7%E5%93%81%E7%AE%80%E4%BB%8B
4. 4. 业界首个"Auto Harness"工程化落地：JiuwenSwarm 给 Harness 装上「后训练」，人人都能 DIY
5. 5. SwarmFlow来了！openJiuwen开创蜂群可控协同新范式
6.