我让智能体学会了组建智能体团队

两个专家 Agent，一次深度改造，一套可复制的方法论。

我开发了两个专家智能体

过去几个月，我先后开发了两个专家智能体：

阿郎：LangChain 框架专家，负责 LangChain 相关的开发咨询和代码生成
阿森：AgentScope 框架专家，负责 AgentScope 相关的开发咨询和代码生成

两个智能体都部署在 QwenPaw 平台上，各有自己的"灵魂文件"（harness）——包括 SOUL.md（知识域）、AGENTS.md（工作流程）、MEMORY.md（记忆）、Skills（工具技能）等。

但用了一段时间后，我发现一个问题：两个智能体的能力差距很大。

问题：同样的框架，不同的能力

阿郎的 harness 改造得很成熟：

SOUL.md 里有完整的 LangChain 知识域划分
AGENTS.md 里有清晰的 5 步调试流程
遇到问题能快速定位，给出准确方案

而阿森还停留在 agentscope 1.0 版本，而且：

SOUL.md 只有通用信念，没有技术知识域
AGENTS.md 流程粗糙，缺乏系统性的调试方法
遇到复杂问题经常"猜"，而不是"查"
现在需要对其升级到 agentscope 2.0，上下文管理难如登天

同样的平台，同样的架构，为什么能力差距这么大？

答案是：harness 的质量决定了智能体的能力上限。

我的思路：分层改造，而不是推倒重来

我没有选择给阿森重新写一套 harness，而是参考阿郎的成熟模式，分层改造。

改造顺序：

SOUL.md（知识域）→ AGENTS.md（流程）→ HEARTBEAT.md（自动化）→ MEMORY.md（记忆）→ Skills（工具）

每一层都是下一层的基础，不能跳步。

第一层：SOUL.md — 注入知识域

这是最关键的一步。我把 AgentScope 2.0 的核心知识拆分成 11 个知识域：

Agent 核心循环
Message & Event 系统
Middleware 中间件
Permission 权限系统
Tool 工具系统
Workspace 工作空间
Service 服务部署
Team 团队协作
Skill 技能系统
MCP 协议集成
常见问题速查

为什么是 11 个？ 因为这是 AgentScope 2.0 的完整知识版图。每个知识域覆盖一个专业领域，智能体遇到问题时，先判断属于哪个域，再在该域内查找答案。

第二层：AGENTS.md — 固化工作流程

我设计了三层递进查询模式：

第一层：知识域速查（秒回，覆盖 80% 常见问题）
    ↓ 搞不定
第二层：reference 深入（场景化，症状→原因→方案→教训）
    ↓ 还搞不定
第三层：源码 API 精确查询（签名、参数、返回值）

这个模式模拟了人类专家的工作方式：

先凭经验快速判断
再查文档深入分析
最后看源码确认细节

同时，我还加了 13 项代码检查清单、文档追踪习惯等。

第三层：HEARTBEAT.md — 自动化巡检

让智能体定期自我检查：

🔴 紧急问题：立即处理
🟡 重要问题：当天处理
常规问题：定期处理

第四层：MEMORY.md — 长期记忆

记录改造经验、踩坑记录、最佳实践，让智能体持续进化。

第五层：Skills — 工具技能

把 6 个分散的 1.0 skill 整合成 1 个统一的 agentscope-dev-guide，包含 11 个 reference 文档。

发现：智能体可以组建智能体团队

改造完成后，我做了一个测试：让阿森自己设计一个日程提醒 Agent。

阿森的表现让我惊喜：

需求分析：判断 PoC 阶段不需要中间件
方案设计：FunctionTool 封装时间解析 + JSON 文件存储 + 外部 cron 触发
权限配置：ACCEPT_EDITS 即可
代码生成：给出了完整的 SubAgentTemplate 配置

这意味着什么？

阿森从一个"被改造的对象"升级成了"agent 管理者"。它可以：

分析业务需求
判断是否需要中间件/权限/workspace
规划 harness 配置
生成 SubAgentTemplate 代码

我发现了一个重要的能力：智能体可以组建智能体团队。

收获：三个关键洞察

洞察 1：三层递进查询模式是核心

这个模式让智能体具备了"专家直觉"：

80% 的问题在第一层就能解决（秒回）
15% 的问题需要第二层深入（分钟级）
5% 的问题需要第三层查源码（但一定能解决）

这个模式可以推广到任何专家智能体。

洞察 2：SubAgentTemplate 是组建团队的关键

SubAgentTemplate 可以定义可复用的 agent 蓝图，不同业务只需不同配置：

# 简单业务：默认配置即可
SubAgentTemplate(
    permission=ACCEPT_EDITS,
    tools=[FunctionTool(time_parser), FunctionTool(json_storage)],
    middleware=[]  # 不需要中间件
)

# 复杂业务：需要中间件和权限控制
SubAgentTemplate(
    permission=BYPASS,
    tools=[...],
    middleware=[SuperpowersMiddleware(), PermissionMiddleware()]
)

分级处理策略：

简单业务 → 默认配置
复杂业务 → 加中间件/权限/workspace

这样既保证了灵活性，又避免了过度设计。

洞察 3：智能体的角色可以升级

阿森的角色转变：

开发者 → 改造对象 → agent 管理者 → 团队组建者

一旦智能体具备了"组建团队"的能力，它就可以：

管理多个子智能体
根据任务类型调度不同的专家
汇总各子智能体的结果
持续优化团队配置

方法论：Harness 改造四步法

基于这次实践，我总结出一套可复用的方法论：

步骤 1：对比分析

把两个 harness 的每个文件逐一对比，找出差距。不要急着改，先看清楚差在哪里。

关键问题：

知识域是否完整？
工作流程是否清晰？
工具技能是否覆盖核心场景？

步骤 2：分层改造

按照 SOUL.md → AGENTS.md → HEARTBEAT.md → MEMORY.md → Skills 的顺序改造。

每一层的改造目标：

SOUL.md：注入完整的知识域
AGENTS.md：固化工作流程和查询模式
HEARTBEAT.md：建立自动化巡检机制
MEMORY.md：记录经验和最佳实践
Skills：整合工具技能

步骤 3：保持风格一致

不同智能体有不同的风格：

阿郎：言简意赅
阿森：技术严谨

改造时保留各自特色，不要变成"克隆体"。

步骤 4：PoC 验证

用实际项目验证改造效果。我们选了日程提醒 Agent，因为：

简单业务（不需要中间件）
能验证完整流程（需求→分析→配置→代码）
有实际价值（真的能用）

适用场景：这套方法能用在哪些地方？

场景 1：长任务执行

问题：需要多个步骤、耗时较长的任务，单个智能体容易"忘记"或"迷路"。

解决方案：

主智能体负责任务分解和进度跟踪
子智能体负责具体执行
通过 Event System 异步通信
主智能体定期 heartbeat 检查进度

例子：

批量处理 100 个文档的摘要生成
多步骤的数据清洗和转换
长视频的分析和剪辑

场景 2：复杂任务执行

问题：需要多领域专业知识的任务，单个智能体无法覆盖所有领域。

解决方案：

主智能体扮演"指挥官"角色
根据任务类型调度不同的专家智能体
通过 Middleware 拦截和协调
汇总各子智能体的结果

例子：

云资源部署（需要 IaC、费用估算、建栈等多个专家）
全栈开发（需要前端、后端、测试、文档等多个专家）
内容创作（需要选题、写作、配图、排版等多个专家）

场景 3：组建智能体团队

问题：需要多个智能体协作完成一个项目，但缺乏统一的管理机制。

解决方案：

用 SubAgentTemplate 定义可复用的 agent 蓝图
不同业务只需不同配置
主智能体管理所有 agent 的生命周期
分级处理：简单业务用默认配置，复杂业务才加中间件

例子：

多业务 Agent 平台（每个业务一个 agent）
智能体开发团队（架构师、开发、测试、文档各司其职）
个人助理团队（日程、邮件、消息、文件管理）

场景 4：智能体自我进化

问题：智能体需要持续学习和改进，但缺乏系统性的方法。

解决方案：

三层递进查询模式（知识域→reference→源码）
自我优化体系（记录错误、修正、学习）
定期回顾和更新 harness

例子：

专家智能体的知识域持续扩充
调试流程的持续优化
工具技能的持续迭代

场景 5：多租户 SaaS 服务

问题：需要为不同用户提供隔离的智能体服务。

解决方案：

Agent Service 提供多租户多会话支持
Workspace 提供环境隔离（Local/Docker/E2B）
Permission System 控制权限边界

例子：

AI 编程助手 SaaS（每个用户一个隔离环境）
智能客服系统（每个客户一个会话实例）
教育平台（每个学生一个学习助手）

我的观察：AI 协作的三个趋势

基于这次实践，我观察到三个趋势：

趋势 1：从"单个智能体"到"智能体团队"

过去的 AI 应用大多是单个智能体完成任务。未来，智能体团队会成为主流：

主智能体负责协调和管理
子智能体负责专业领域
通过标准化接口协作

趋势 2：从"硬编码"到"可配置"

过去的智能体行为是硬编码的。未来，可配置的智能体会成为主流：

SubAgentTemplate 定义蓝图
不同业务只需不同配置
快速部署和迭代

趋势 3：从"被动响应"到"主动管理"

过去的智能体是被动响应用户请求。未来，主动管理的智能体会成为主流：

智能体可以组建团队
智能体可以管理生命周期
智能体可以持续进化

下一步：多业务 Agent 平台

基于这次改造，我有一个更大的构想：

以 AgentScope 2.0 的 agent_service 为基础平台，把个人小业务都做成平台上的不同 agent。

简单业务（不需要中间件）→ 阿森直接规划 harness + 创建 SubAgentTemplate 配置
复杂业务（需要中间件/权限/workspace）→ 阿森开发中间件等高级功能
阿森的角色升级：从"开发者"→"agent 管理者"，管理平台上所有 agent 的生命周期

这就像是一个智能体工厂：

用户提出业务需求
阿森分析需求，判断复杂度
阿森规划 harness 配置
阿森生成 SubAgentTemplate 代码
新 agent 上线，开始服务

总结

这次实践让我发现：智能体可以组建智能体团队。

关键要素：

分层改造 harness：SOUL.md → AGENTS.md → HEARTBEAT.md → MEMORY.md → Skills
三层递进查询：知识域速查 → reference 深入 → 源码 API 精确查询
SubAgentTemplate 配置：定义可复用的 agent 蓝图
分级处理策略：简单业务用默认配置，复杂业务才加中间件
智能体角色升级：从"开发者"→"agent 管理者"

这套方法不仅适用于 AgentScope，还可以推广到任何多智能体协作场景。

未来已来，只是分布得不均匀。 而我们要做的，就是让智能体学会组建智能体团队。

作者：加加（公众号"加加笔记"主理人）

2026-06-14

我让智能体学会了组建智能体团队

Table Of Content