Paca：把 AI Agent 当成 Scrum 团队里的正式成员

Jira、ClickUp 这类项目管理工具都在往里塞 AI，但多数还是把 AI 当”外挂助手”——你问它答。Paca 反过来：从数据模型层面就把 AI Agent 当成敏捷团队的一员，和人在同一块看板上协作。官网标题写得直白：“Humans and AI agents, one Scrum team.” 本文基于其官网与项目库信息分析。

一、它是什么

Paca 自称 “AI-native. Free. Lightweight. Open-source.”（Apache-2.0，GitHub 约 1.9k star）。核心场景：在一块人机共用的看板上，AI 可以主动领取任务、更新状态，和人类实时协作，而不是等人手动派活。

它把 PDCA（Plan–Do–Check–Act）循环直接做成了命令：

• /paca-sprint、/paca-epic、/paca-do 等十余个斜杠命令；
• 内置 MCP server，让 Claude 等 Agent 直接读写看板；
• 提供 Claude Code skill，把 Paca 的工作流接进编码 Agent。

二、工程实现（项目库可核实）

据项目库条目，其技术选型包括：

• 实时协作：Socket.IO 做看板的实时更新；
• 插件沙箱：WASM 沙箱跑插件，给 Agent 行为一个隔离边界；
• 变更可追溯：所有改动带前后 diff，支持一键回滚；
• 自然语言规划：可在项目级聊天里用自然语言规划工作；
• 自托管：Docker Compose 一键起，数据不依赖外部 SaaS。

三、口径偏差与理念评估

1. “Agent 是团队成员”是理念，成熟度待验：把 Agent 当一等公民这个想法很激进、也贴近 Agent 协作的未来形态，但项目库点评也提醒——实际落地还要看它真正解决问题的能力，不能只看概念。
2. 把沙箱、代码变更耦合在一起是双刃：项目库点评指出，“将沙箱、代码变更都耦合在一起的设计在复杂场景中可能成为减分项”——强耦合换来了一体化，也牺牲了灵活性。
3. star 数是时点数据：约 1.9k star 是官网抓取时的数字，早期项目增长快、流失也快，不能直接等同于采用率。
4. 它是项目管理工具，不是 Agent 本身：Paca 提供的是”看板 + 接口”，真正干活的 Agent 还是你接进来的 Claude 等；它的价值在于协作流程，不在于模型能力。

四、适用 / 不适用

适合：

• 已经在用多个 AI Agent 并行干活、缺一块”人机共用任务板”的小团队；
• 想让 Agent 主动领活、而不是人逐条派任务的工作流；
• 重视自托管、数据不出自己基础设施的团队。

不适合：

• 已经重度依赖 Jira/Linear、迁移成本高的成熟团队；
• 只想要个”AI 写周报/写需求”的轻量助手，不需要 Agent 领任务的人；
• 期待它自带强 Agent 能力的用户——它只是协作层。

五、它意味着什么

Paca 押注的是一个判断：未来的软件团队不是”人 + 几个 AI 工具”，而是”人和 Agent 混编”。当 Agent 能自己看 backlog、领任务、更新状态、提 diff，项目管理工具的数据模型就得从”给人点的看板”变成”人机共写的看板”。这个方向值得关注，但它能否成立，取决于 Agent 自主领任务的可靠性——领错了、做错了，反而比手动派活更难收拾。理念领先，工程待验。

参考来源

• Paca 官方网站
• Koala 项目库条目：Paca