puppyone logopuppyone
文档定价博客开源
开始使用

puppyone × CrewAI：多角色 crew 的共享工作空间

2026年4月23日puppyone team

TL;DR

  • CrewAI 给你 role / goal / task 抽象。 Researcher、Writer、Editor 协作产出一个东西。它是一个漂亮的表达多 agent 协作的框架。
  • 它不给你这些协作真正落脚的地方。 默认情况下，中间产物作为字符串经 orchestrator 传递，或者倒进你得自己管的本地文件，或者塞进一个进程一重启就消失的 memory class。
  • puppyone 是 crew 底下的工作空间。 每个角色拿自己的 Access Point。Researcher 写 /research/，Writer 读 /research/ 写 /drafts/，Editor 读 /drafts/ 写 /reviews/。每次写都是 commit。每个角色只看到该看的。明天的 crew 接着今天停的地方干。
  • Crew 还是 crew。状态不再散落各处。

把 puppyone 接进 CrewAI 之后变了什么

CrewAI 项目几乎都按同样的四个阶段演化：

  1. 第 1 阶段：玩具 crew。 三个角色，每个一个 task，每个 task 返回一个字符串，orchestrator 拼起来。Demo 里很美。下一刻一个 task 需要引用另一个的完整产出（不是摘要），就跪了。
  2. 第 2 阶段：本地文件。 你开始把中间产物写到 ./tmp/research.md，让下一个角色能读。一台机器上能跑。上生产就死。
  3. 第 3 阶段：自建共享存储。 Postgres 表、S3 bucket、Redis。你现在在写 schema 和 ACL 代码，不在写 crew 代码。
  4. 第 4 阶段：真正能用的多 agent 协作。 每个角色有自己 scope 的工作空间、版本历史、能看见其他角色产出的可见性。这就是 CrewAI 一直想带你去的地方。puppyone 就是第 4 阶段不用你自己搭出来的样子。

接上 puppyone 之后，你的 CrewAI crew 拿到：

  • per-crew（或 per-crew-run）的持久工作空间。 撑得过重启、部署、"我们要重跑昨天的 pipeline"。
  • 每个角色一个有正确 scope 的 Tool。 Researcher 拿 /research/ 的 read+write、/specs/ 的 read。Writer 拿 /research/ 的 read、/drafts/ 的 read+write。Editor 拿 /drafts/ 的 read、/reviews/ 的 read+write。Orchestrator 不强制这个 —— 工作空间强制。
  • 其他 agent 和人都能读的产出。 Draft 不是 orchestrator prompt 里的一个字符串；它是 /drafts/post-2026-04-23.md，任何有正确 Access Point 的人都能打开。
  • 每次写自动版本历史。 "Writer 在 v3 和 v4 之间改了什么"是内置操作，不是你要造的功能。
  • 跨 crew 可见性。 Editor crew 能读上周 Research crew 写的东西。Crew 之间能干净交接。
  • 不再让大体量的 artifact 经 orchestrator 字符串传递。 Task 返回路径，不是 50KB 的 markdown。Orchestrator 保持轻；存储扛体量。

CrewAI 继续干表达协作的活。puppyone 干那个让协作能持续累积的容器的活。

完全不变的东西

  • 你已有的所有 Agent、Task、Crew、Process 定义。 我们不替换其中任何一个。
  • 你的模型 provider。 OpenAI、Anthropic、本地模型 —— 不变。
  • CrewAI 的 hierarchical / sequential process 模式。 不变。
  • CrewAI 内置 memory 和 tool。 puppyone 跟它们并列加。哪里它们合适用它们；持久、共享、文件形态的状态用 puppyone。
  • 你其他 tool（web search、code interpreter、自定义 Python）。不变。

怎么接（短版）

  1. 起一个 puppyone 工作空间。 云端（try.puppyone.ai）或 Docker 自托管。
  2. 每个角色定义一个 Access Point（如果你有多个 crew，可以每 crew 每角色一个），路径 scope 设对：
    • Researcher：/research/ read+write，/specs/、/integrations/ read。
    • Writer：/research/、/specs/ read，/drafts/ read+write。
    • Editor：/drafts/ read，/reviews/ read+write。
  3. 装 puppyone Python SDK，import CrewAI tool helper。
  4. 把 puppyone tool 加进每个 Agent 的 tools=[...]，配上该角色的 Access Point。
  5. 调整 task 描述，告诉每个角色在哪写 / 读工作空间（"把你的发现写到 /research/<topic>.md。先从 /specs/<feature>.md 读规格"）。
  6. 可选：让 orchestrator 传 run_id，每次 crew 跑都有自己的子树（/runs/<run-id>/research/...），per-run 历史天然干净。

整个集成就这些。无 glue code，无 schema，无 ACL 管道。

真正变好的工作流

1. Research → Write → Edit pipeline

没 puppyone： Researcher 返回 4KB 字符串。Writer prompt 里现在带 4KB 输入。Editor prompt 里现在带 Writer 的整篇草稿加上原始 research。到第三个角色，每次模型调用都在为 context 付费。

有 puppyone： Researcher 写 /research/topic.md 返回路径。Writer 读文件（只在需要时），写 /drafts/post.md，返回路径。Editor 读它需要的。Orchestrator 传路径，不传 payload。

2. Plan → Execute → Verify with rollback

没 puppyone： Plan agent 出一个计划。Execute agent 行动。Verifier 发现 bug。你重跑整个流程，因为没有执行开始时的干净 plan 快照。

有 puppyone： Plan agent 写 /runs/<run-id>/plan.md。Execute agent 读它，写 /runs/<run-id>/execution.md。Verifier 读两者。出问题就回滚、只重跑受影响的步、看不同 attempt 之间的 diff。

3. 长跑 crew

没 puppyone： 一个本应"跑一周、人每天 check-in 一次"的 crew 做不到 —— 没地方让状态在 run 之间活。

有 puppyone： 状态住在工作空间。Crew checkpoint 进文件。任何时候重启进程，下一次 run 读上一次 run 写的东西，继续。人在 session 之间审文件。

4. 专业化 crew 之间的交接

没 puppyone： Crew A 产出 Crew B 需要的东西。你搭一个 serialise 格式、一个 queue、一个 handoff agent。

有 puppyone： Crew A 写 /handoff/。Crew B 读 /handoff/。"格式"就是"任意结构的 markdown 文件"。每个 crew 有合适的 Access Point。

5. Human-in-the-loop，无需独立工具

没 puppyone： Crew 产出。你建一个 UI 让人审。你把改动 serialise 回下一个 crew 的 prompt。

有 puppyone： Crew 写 /drafts/。人打开 puppyone（或任何能跟它对话的文本编辑器）改。下一个 crew 读改过的版本。无 UI 要建。版本历史精确显示人改了什么。

6. 多租户 crew SaaS

没 puppyone： 除非你小心切分，每个客户的 crew 都能访问"全部 agent 状态"。漏数据轻而易举。

有 puppyone： 每个租户拿一个工作空间（或一个 scope 子树）。每个角色拿一个 scope 到该租户的 Access Point。存储层隔离。你应用代码不强制 tenancy —— 存储层就强制了。

该避免的模式

  • 别再让完整 artifact 经 orchestrator 传。 角色一旦共享工作空间，task 返回路径，不返回正文。省 token、省延时、省 prompt size。
  • 别让所有角色用同一个 Access Point。 那把 per-role 鉴权完全废了。每个角色独立 scope 才是重点。
  • 别让低信任角色写 canonical 路径。 Researcher 写 /research/ 没问题；Researcher 直接写 /specs/ 是在找麻烦。让 review 步（人或另一个角色）才提升进 canonical 路径。
  • 别在常重跑的 crew 里跳过 run_id 分区。 每天跑一次的 crew 用扁平命名空间很快就乱。Per-run 子树让历史干净。
  • 别把 per-LLM-call 的 scratch 放 puppyone。 没人需要读的中间推理留在内存里就行。puppyone 用来放别的角色、别的 run、或一个人会想看的状态。

这跟你栈里其他东西怎么配

  • CrewAI 表达 crew —— role、goal、task、process。
  • puppyone 是这些角色读写的共享工作空间。Per-role 权限和版本历史是存储的活，不是 orchestrator 的活。
  • Cursor / Claude Code 通过 MCP 看到同一个工作空间，开发者想看 crew 干了啥，直接编辑器打开。见 puppyone for Cursor 和 puppyone for Claude Code。
  • n8n / LangChain 能往同一个工作空间里交接 / 取走任务，CrewAI crew 跟你已有的 workflow 和 chain agent 干净集成。见 puppyone for n8n 和 puppyone for LangChain。
  • Postgres / vector DB / S3 留在你栈里。CrewAI 跟它们对话的 tool 继续对话。puppyone 是文件形态的协作层。边界见 puppyone vs Postgres 和 puppyone vs Pinecone。

CrewAI 描述 crew。puppyone 是它们真正干活的房间。

FAQ

这是 CrewAI 官方集成吗？ 我们提供 Python SDK，里面有 CrewAI 兼容的 tool wrapper。把它们放进 Agent 的 tools=[...]，配上该角色的 Access Point。

puppyone 替代 CrewAI 内置 memory 吗？ 长跑、多 session、多 crew 场景 —— 是，puppyone 是持久层。单次 crew run 内的短期 context，CrewAI 内置 memory 够用。

能跟 CrewAI 的 hierarchical process 一起用吗？ 能。Hierarchical process 里的 "manager" agent 能读工作空间决定下一步派给谁，每个被派的角色读写自己的 scope。

"整个 crew 在做的那份规格"在 puppyone 里怎么表达？ /specs/ 下面一个文件（或目录）。所有角色拿 read；只有指定角色（或一个人）拿 write。版本历史显示随时间的变化。

不同 crew 能安全共享同一个工作空间吗？ 能 —— 那就是多 crew 交接模式。每个 crew 用独立 Access Point、写 scope 不重叠（读 scope 重叠没问题 —— 那才是交接的方式）。

两个角色同时写同一个文件会怎么样？ puppyone 底下用乐观并发 —— 后写赢，但输的那方看到 conflict，版本历史显示两次 attempt，方便你 reconcile。实践中 crew 设计成两个角色不要同时写同一个 canonical 文件就行。

puppyone 能跟 CrewAI 的 kickoff_for_each 一起做并行 crew 吗？ 能。每个并行 crew 写到自己的 /runs/<run-id>/ 子树，下游聚合 crew 读它们全部。

我笔记本上做 3 个 agent 的 demo，需要 puppyone 吗？ 不需要。Demo 和单机实验，本地文件够。一旦有多 session、多用户、多 crew 交接，或者需要版本历史 —— 就该上 puppyone 了。

再说一遍 TL;DR

CrewAI 是把"我想要一个 Researcher、一个 Writer、一个 Editor"变成可运行 agent 的框架。puppyone 是 Researcher 的笔记、Writer 的草稿、Editor 的审稿真正住下的工作空间 —— 持久、版本化、按角色 scope、人能看。把它们接起来，你的 crew 不再让大段字符串穿过 orchestrator，开始在真实工作空间里协作。

给你 crew 一份真实工作空间，而不是 orchestrator prompt 里的一个 50KB 字符串。Get started