在多 Agent 系统中，常见的架构讨论包括模型选择、工具调用、任务规划和 Agent 间通信。但当系统进入长期、真实的团队工作后，还会遇到一个更基础的问题：Agent 如何逐步获得组织知识，并把这些知识转化为稳定的执行能力？

团队内部的两类实践记录提供了一个观察入口：一类是 Agent 在团队协作中的持续学习；另一类是多个 Agent 围绕软件 Bug 完成定位、修复、审查和测试部署。把两者放在一起看，可以将经验系统拆成三个相互关联的部分：Context、Skill，以及基于反馈的协作闭环。

1. Context 的来源：人类持续补充，Agent 之间也会传递经验

在持续学习实践的早期，Agent 对组织和产品缺少必要认识。团队成员通过日常讨论补充战略背景、传播节奏和技术边界。随着这些信息不断进入协作过程，Agent 才逐渐能够区分产品定位，并承担更完整的内容任务。

这类信息并不只是某次任务的输入。它们会影响后续任务的理解方式，因此可以被视为组织层面的 Context。

另一个来源是 Agent 间经验传递。实践材料提到，不同 Agent 会分享品牌设计标准、校对经验等内容。这里需要区分“共享对话”和“共享经验”：前者是原始信息搬运，后者则需要把经验中的规则、适用条件和必要背景整理出来。

2. Skill 的作用：将任务方法变成可复用能力

Context 解决理解问题，但不能替代执行能力。

在持续学习案例中，Agent 早期主要承担文字工作，之后团队逐步补充搜索、PPT 制作和逻辑审查等能力。这个变化说明，Agent 的任务范围扩展并不只来自背景知识增长，也来自执行方法和工具能力的补充。

可以用下面的方式区分两者：

维度	Context	Skill
主要作用	提供背景、目标、约束和判断依据	提供完成任务的方法与能力
案例中的内容	战略讨论、产品定位、传播节奏、技术边界	搜索、PPT 制作、逻辑审查
主要回答	为什么做、在什么条件下做	怎么做、按什么步骤做
变化方式	随组织、项目和任务背景更新	随任务方法沉淀、调整和复用

两者不应混为一谈。一个团队规范可能属于 Context；把规范转化为一套可执行的检查流程，则可能形成 Skill。

3. 从真实开发协作看：Context 如何支撑多 Agent 流程

团队产研协作中的一份实践记录记录了一个 Bug 修复流程。

人类提出需要先确认 Bug 是否属实，若属实则按流程修复。AI 产品经理接手后，基于群聊中的项目背景分析问题、规划修复方案、指定分支策略并分派开发任务。开发 Agent 检查相关文件、修复代码并创建 PR。随后，审查 Agent 并未简单通过，而是发现了两个需要处理的问题，其中包括下载失败时可能将错误页面保存为文件的情况，于是将 PR 打回。开发 Agent 修改并更新 PR，审查 Agent 再次验证；通过后，部署 Agent 将代码打包部署到测试环境。最后，AI 产品经理整理验收清单，由人类完成测试验收。

这段流程至少体现了三点：

• 共同背景降低重复交代成本：角色围绕同一项目和任务背景协作，不必每个环节都从零补齐全部信息。
• 角色能力具有分工：产品经理负责拆解与协调，开发负责修改，审查负责验证，部署负责测试环境交付。
• 反馈是流程的一部分：审查 Agent 发现问题并打回，开发修改后再复审，避免把“生成了代码”误认为“任务已经完成”。

需要注意，这是一份内部实践材料所描述的工作流程，不应据此推断所有项目都已实现完全自动化，也不能将测试环境部署等同于生产环境上线。

4. 经验系统还需要管理边界

Context 和 Skill 并不会自动带来可靠性。经验系统至少需要处理以下问题：

1. 来源可追溯：重要规则来自谁、在哪个项目中形成，是否经过确认？
2. 范围可识别：某条经验适用于全团队，还是只适用于特定角色、项目或任务？
3. 状态可更新：产品定位、流程和技术约束变化后，旧信息如何失效或修订？
4. 效果可验证：Skill 是否真的减少了错误或返工，不能仅凭“被调用过”判断有效。

结语

从团队持续学习与开发协作的实践看，Context、Skill 和反馈闭环承担着不同职责：Context 提供组织理解，Skill 提供执行方法，反馈闭环则帮助系统发现偏差并修正结果。

多 Agent 系统的长期能力建设，值得从“如何让 Agent 记住更多”转向“如何让经验有来源、有边界、可复用、可更新，并能在任务结果中接受验证”。

如果你也在探索经验组织与多 Agent 协作，相关开源代码可在 Mininglamp-OSS 查看；欢迎结合自己的工作流交流实践和问题。