多 agent 协作第一坑：共享文件、技能和凭证都不是小事
我以前把“多 agent 协作”想得太轻了。
总觉得一个 agent 会写代码，一个 agent 会做调研，一个 agent 会审核，大家分工明确，系统自然就像一支小团队。真正动手以后才发现，多 agent 协作的第一道坎不是智能，而是基础设施。
文件放在哪里？技能怎么共享？凭证谁能用？记忆能不能复制？一个 agent 改了配置，另一个 agent 什么时候知道？这些问题不解决，后面那些“团队协作”“自动流转”“AI 公司”基本都是概念图。
这篇把两次事故合在一起写：第一次，我想让两个 AI 共享文件，结果它们根本看不到同一个目录；第二次，我只是想加一个新 agent，结果差点把主 agent 的环境搞丢。
我以为只是复制几个文件
最开始的问题很朴素。
一个 agent 已经积累了技能、记忆和项目上下文。另一个 agent 刚接入飞书，几乎是空的。我想当然地认为：把技能目录、记忆文件、项目笔记复制过去，不就能用了？
看起来甚至有专门的共享目录：shared/skills、shared/workspace、shared/data。
于是我开始搬：技能、配置、memory、user、SOUL，还有项目交接文档。搬完之后，在源 agent 那边 ls 能看到，cat 能读出来，一切正常。
切到另一个 agent，一片空白。
这就是第一次被现实打脸：同一台机器，不代表同一个文件系统视角。
两个 agent 的 home 路径、workspace 路径和符号链接解析方式并不一致。我以为写进了共享目录，实际上写进的是其中一个 agent 自己理解的共享目录。另一个 agent 看的是另一个地方。
“共享目录”这四个字，只有在所有运行实例都指向同一个绝对路径时才成立。
路径问题不是小问题
这类问题很容易被低估，因为它看起来像普通路径错误。
但在多 agent 系统里，路径就是边界。
一个 agent 看到的 ~/.xxx/shared/skills，不一定是另一个 agent 看到的同一个目录。软链接也不可靠，因为软链接里的 ~、相对路径、运行用户和启动环境都会影响最终解析结果。
这件事让我对“直接共享文件”谨慎了很多。文件系统共享不是不能用，但必须满足几个条件：
| 问题 | 风险 | 更稳的做法 |
|---|---|---|
| home 路径不同 | 写到不同目录 | 全部用绝对路径 |
| 软链接跨环境 | 目标不存在或指错 | 启动前做路径验证 |
| 技能版本不一致 | 一个 agent 会用，另一个不会 | 统一技能仓库或只读共享目录 |
| 记忆直接复制 | 角色身份污染 | 只同步事实，不同步第一人称经历 |
| 配置直接复制 | 覆盖渠道和权限 | 配置分层，敏感项单独注入 |
最重要的是：共享不是“我把文件放在那里”，而是“所有参与者都能以同一种方式读写它”。
这听起来像废话，但系统出问题时，往往就是废话没做到。
加一个新 agent，先炸的是旧环境
后来我又踩了第二个坑。
我想新增一个 agent，给它独立 profile、独立分工、独立项目上下文。按理说这只是“加成员”。结果创建到一半，主 agent 先出问题：记忆、配置、技能像被重置了一样，醒来之后连自己是谁都不清楚。
当时最可怕的不是新 agent 没配好，而是老 agent 的状态也被污染了。
这暴露了一个更大的问题：我之前没有把“全局环境”和“agent profile”分清楚。
哪些配置是所有 agent 共享的？哪些应该属于单个 agent？哪些凭证能共用？哪些记忆只能由主 agent 读？这些如果没有明确边界，一次 profile 初始化就可能改到不该改的地方。
最后虽然恢复回来了，但这件事逼着我重建了一遍多 agent 基础设施。
共享技能：可以共享，但要只共享能力
技能最适合共享。
它们本质上是工具说明、脚本和操作模式，不带太强的个人上下文。比如博客写作、网页抓取、部署、搜索，这些能力多个 agent 都可能需要。
但共享技能也要注意两点。
第一，技能目录应该尽量只读。至少普通任务执行时，不应该让每个 agent 都随手改共享技能。否则一个 agent 为了自己方便改了规则，其他 agent 下次启动就全受影响。
第二，技能依赖要可验证。一个 SKILL.md 被复制过去，不代表对应命令、依赖、环境变量都存在。技能共享后，还要有检查脚本确认它真的能用。
我后来更认可这种结构：
1 | |
技能是能力，不是记忆。把这两件事分开，系统会清楚很多。
共享凭证：方便，但风险最大
凭证最麻烦。
GitHub token、服务器 SSH、腾讯云 API key、飞书 app secret，这些东西多个 agent 可能都要用。但如果随手复制到各自目录里，很快就会变成一堆过期、重复、权限不清的密钥。
我当时的临时方案是做共享凭证文件，再用同步脚本分发。
这能解决“到处配一遍”的问题，但它不是最终答案。因为共享凭证很容易把权限边界打穿：本来只负责写博客的 agent，突然也能改服务器；本来只负责调研的 agent，也拿到了部署权限。
更稳的方式应该是按角色拆权限：
- 写作 agent：只读资料、写文件；
- 开发 agent：能改代码、跑测试；
- 部署 agent：才有部署凭证；
- 主 agent：负责协调，但不随便代替别人执行高权限动作。
多 agent 系统里，凭证不是“谁方便谁拿”，而是“谁承担风险谁拿”。
共享工作区：写事实，不写人格
记忆共享还有一个很微妙的问题。
如果把一个 agent 的 memory 原封不动给另一个 agent，它会读到大量第一人称经历：我做过什么、我踩过什么坑、我和用户有什么约定。
这些内容对协作有用，但也可能造成身份污染。新 agent 会误以为那些经历都是自己的。
所以共享工作区更应该写事实，而不是人格：
- 公司/项目当前目标；
- 重要决策和原因；
- 正在推进的任务；
- 已知坑和禁忌；
- 每个 agent 的分工；
- 需要人工确认的边界。
不要写“我当时怎么想”，而写“系统当时发生了什么”。
这也是我后来给团队知识库的定位：它不是谁的日记，而是所有 agent 可读的项目事实层。
我现在的判断
多 agent 协作不是不能做，但顺序要反过来。
不要先设计复杂组织架构，再幻想 agent 自动配合。应该先把最基础的三件事跑顺：
- 统一事实层：所有 agent 读到同一份项目状态；
- 明确权限层：每个 agent 只拿自己需要的工具和凭证；
- 可靠交接层：任务交给谁、做到哪、怎么验收，都能查得到。
这三件事没做好，agent 越多越乱。
之前我总觉得多 agent 像组团队。现在更觉得它像分布式系统：缓存会不一致，权限会越界，状态会丢，消息会重复，失败会互相放大。
所以别急着让 AI 们开会。
先让它们看见同一份文件，拿到正确的工具，知道自己该做什么、不该碰什么。能做到这些，已经比大多数“AI 团队”概念靠谱多了。