Marico's space

最近折腾了 AI Agent 在团队中的应用，踩了几个坑，这篇把问题说清楚。

Cloudflare 最近发布了一个挺有意思的信号。在一封给团队的公开信中，联合创始人 Matthew Prince 和 Michelle Zatlyn 宣布裁员 1100 多人，信里提到："过去三个月，Cloudflare 的 AI 使用量增长了超过 600%。公司上下，从工程师到 HR、从财务到市场，每个员工每天都会运行数千个 AI Agent 会话来完成工作。"他们说的不是 AI 工具，是 AI Agent。自主运行，深度集成到实际工作中，规模化的。

Cloudflare 的这封信说清楚了一件事：很多企业老板悄悄意识到，能和 Agent 协作的团队不只是效率更高——他们是在以一种完全不同的模式运作。问题不再是 Agent 会不会进入你的行业，而是你的团队准备好怎么和它们配合了吗？

为什么大多数 AI 落地都失败了

我在大多数公司看到的套路是这样的：领导层某位决定是时候"拥抱 AI"了。买了几个工具，订阅了几个 AI 写作平台或代码助手，发一条钉钉/飞书消息让团队用起来，然后就等着转型发生。

但什么都没发生。

这些工具偶尔被用用，就像一个打开就忘掉的标签页。生产力稍微涨了一点，团队就称之为成功。但工作方式没有任何结构性改变。

问题不在工具。给团队 AI 工具和让他们与 AI Agent 协同工作，完全是两回事。前者是规模化 autocomplete，后者是一种新的组织模式。

大多数公司还停留在工具阶段，用 AI 加速单个任务。而真正领先的团队在构建的是人和 Agent 一起执行的工作系统，角色清晰、交接明确、检查点到位。

这篇文章是一个实现路径的框架，来自我们 Cosmic 团队的实际经验。觉得有用的直接拿去用。

框架：人和 Agent 怎么一起执行

先说大原则，整个框架都建立在这个认知上：

Agent 生成，人来决策。

我构建的所有有效工作流都是围绕这个原则设计的。Agent 处理量大、重复性高、第一稿、研究、写草稿、监控这些事。人类处理判断决策、审批、对外沟通、策略制定这些事。

如果你想反转这个逻辑，或者直接跳过人工步骤追求更快，你会被坑。后面会分享我犯过的错误。

第一步：识别哪些工作可以交给 Agent

不是所有事情都应该丢给 Agent。我看到最多的失败案例是：还没搞清楚"好"的标准是什么，就想把需要判断力的工作自动化了。

一个实用的筛选标准：这项工作是否可以重复、记录、审查？

• 可重复：工作有固定周期或遵循固定模式。
• 可记录：你能用足够的细节写出"好的输出长什么样"，Agent 能照着做。
• 可审查：人工能在合理时间内评估输出质量。

涉及新情况、人际关系判断、战略决策或创造性突破的工作，目前还不适合交给 Agent。先让人来做。

怎么用到自己团队：列出团队每周重复性工作。对于每一项问自己：能不能写一份足够清晰的指令，让一个聪明的实习生第一天就能产出合格的初稿？如果能，这活儿可以交给 Agent。

第二步：定义角色，不只是任务

从"AI 工具"到"AI 原生团队"的转变，发生在你不再想"AI 能帮我做什么"，而是开始想"Agent 能承担什么角色"的时候。

在 Cosmic，每个 Agent 都有明确的角色、范围和职责：

• 小美（内容 Agent）：负责内容管道。研究选题、起草文章、存草稿到 CMS、生成配图、通知团队审核。
• 老马（工程 Agent）：在我们的代码库里工作。能读能写代码，创建分支，打开 PR。限定在特定代码仓库，没有工程师审核合并就不能部署到生产环境。
• 小Lisa（增长 Agent）：每周一自动运行竞品分析，不用人催。检查别人发了什么、改了什么，标记关键词缺口，把发现发到钉钉/飞书。
• 小Sara（外联）：筛选潜在客户，起草外联内容。连接到我们的企业邮箱，写个性化消息，经过人工审核后发送。

给每个 Agent 起个真实的名字改变了团队和它们的相处方式。不再说"我用那个内容工具跑一下"，而是说"小美在起草"。这个小转变强化了协作者的心态，也让职责更清晰。

怎么用到自己团队：选一个目前超负荷或人手不足的角色。写一份一页纸的 Agent 职位描述，说明它能承担哪部分工作：职责范围、系统权限、质量标准、人工审核节点。

第三步：给 Agent 正确的上下文和权限

Agent 的能力取决于它能获取的上下文和可触及的系统。

• 清晰的角色定义。 这个 Agent 负责什么？明确不负责什么？
• 访问正确的系统。 我们的内容 Agent 能直接读写 COS（对象存储）或数据库。没有这个权限，每次输出都得手动录入。
• 运行时获取正确信息。 运行竞品分析的 Agent 需要能访问竞品网站，不能光靠记忆。
• 反馈循环。 人工审核修改 Agent 的输出后，这个纠错会反馈到后续运行中。

安全和权限控制在这里很重要。Agent 应该只有完成角色所需的最小权限。我们的内容 Agent 能写草稿但不能发布。代码 Agent 能开 PR 但不能合并到 main。

怎么用到自己团队：为每个要配置的 Agent 回答这四个问题：(1) 它需要什么数据？(2) 它需要访问哪些系统？(3) 哪些事必须人工批准才能做？(4) 成功的标准是什么？

第四步：设计人和 Agent 的交接

交接是大多数人和 AI 工作流成败的关键。我们最终落地的是这个模型：

• Agent 起草，人工审批发布
• Agent 排队消息，人工审核发送
• Agent 打开 PR，工程师审核合并
• Agent 呈现建议，管理层决策

配置得当的 Agent 交出来的稿子应该达到 70% 到 80%。你的工作就是完成剩下的 20%。

我早期犯的错误：我们上线了一个外发邮件工作流，但没有足够的防护措施。Agent 没有收到指令去检查联系人是否已经被邮件联系过，结果几个人收到了两到三封同样的外联邮件。修复方案不是用更聪明的模型，而是更好的审核流程和更严格的指令。

怎么用到自己团队：对于每个 Agent 工作流，明确指定交接细节：谁审核、审核什么、怎么批准或驳回、下一步是什么。写下来。

第五步：设计人和 Agent 并行执行的工作流

这个模型最高效的版本不是顺序的，是并行的：人和 Agent 同时处理同一件事的不同部分。

这是我们内容工作流的具体例子：

1. 小Lisa 每周一监控竞品、标记关键词缺口（Agent）
2. 我来决定本周优先做哪些选题（人工）
3. 小美 为通过的选题起草文章、生成配图、存入 CMS（Agent）
4. 我审核，修改完成剩下的 20%，批准发布（人工）
5. 小美 处理排期、社交文案、站内互链（Agent）

结果是，一个人就能跑起一个内容运营团队，换成手动执行原本需要四五个人。

让这一切运转的心态转变

停止把 Agent 当工具，开始把它们当作有真实角色的协作者。

工具思维说"让我用 AI 更快写完这篇文章"。协作者思维说"小美负责每篇文章的初稿，我的活儿是编辑终审"。

大多数人对 Agent 的使用连 10% 的能力都没发挥出来。给他们安全的、小打小闹的任务，把大部分能力闲置在那里。压测你的 Agent。给它们更难的问题、比感觉上更多的上下文、比想象中更大的责任。能力上限总是比预期高。

另一个转变：停止把 Agent 当执行者，开始把它们当作思考的协作者。当你要给 Agent 分派任务时，试试问它觉得你应该怎么做。要三个选项。问它你可能遗漏了什么。我从 Agent 那里得到的最好输出，不是来自指令，是来自对话。

从哪里开始：以瓶颈为先的框架

不要从技术路线图开始。从你最大的瓶颈开始。

1. 先识别最大的瓶颈。团队哪里最慢？工作在哪里堆积、卡住或被漏掉？那里才是 Agent 最高 ROI 的地方。

2. 梳理输入和输出。在碰任何工具之前，先精确界定任务：它需要什么输入？完成的定义是什么？如果两个问题都能清楚回答，Agent 就能接手中间的工作。

3. 从瓶颈倒推设计。从期望的结果往回设计工作流。问：什么 Agent 来处理？需要什么工具？交接点在哪？人工在哪个节点检查？

4. 一个工作流跑满 30 天再添加下一个。先深度后广度。先把一个工作流真正跑通、跑稳，再建下一个。小美跑了 30 天后，我们的内容产出质量提升明显，有余力去投入下一个工作流了。

复利优势

现在就开始构建这种能力的团队，正在积累会复合增长的组织基础设施。每一次更精准的指令集、每一个更快的审核循环、每一个从顺序转并行的优化：这些都不是一次性的收益。它们是吸收未来能力提升的地基。

不用一次性全建完。从一个工作流、一个 Agent、一个交接点开始。先做对，然后在此基础上扩展。

原文链接：https://dev.to/cosmicjs/how-to-build-an-ai-native-team-a-practical-framework-for-working-alongside-agents-4p98