多数团队把 AI 接进业务流程时的顺序是先连工具、后定规则，结果是几个管理员对同一批 agent 下达彼此冲突的指令，而 agent 无从判断谁说了算。GTM（Go-To-Market，市场进入）团队最容易撞上这堵墙：销售、产品、AI 工作流三方各有一套成立的判断，喂进模型之后变成三条互相竞争的命令。这篇文章拆解一份被称为 Shared Agent Brief 的运营协议——它来自 StartupGTM 作者 Ayush Poddar 在自家 GTM 项目里的实践记录，可以直接照抄到任何多人共用 AI 的场景。一句话结论：上下文决定 AI 知道什么，决策权决定 AI 听谁的，后者无法靠喂更多上下文补齐。
一、失灵的现场：三个管理员，四条都成立的指令
这套东西的起点是一个具体的僵局。团队三个人同时是 AI 的管理员，各自负责一段：
| 角色 | 负责的部分 |
|---|---|
| 销售 | 从客户对话带回市场视角：该打哪些公司、哪些购买信号重要、走什么渠道、什么话术能开启真对话 |
| 产品 | 把工具缝成技术栈：信号 → 客户和买家 → 触达 → 温暖回复 |
| AI 工作流 | 底层链路：研究客户 → 给信号打分 → 推断商业压力 → 建立观点 → 找对的人 → 起草触达 |
值得强调的是，这个团队的上下文栈已经相当完备，甚至用了自我演化的 llm-wiki 来沉淀记忆。卡住他们的是另一件事：三个人的指令不同步，而 AI 不知道每一个决定该由谁的意见统治。
让问题浮出水面的是一个具体的设计决策——要不要把「高管换工作」和「新任高管」当作目标筛选信号。
销售假设很直白：一个最近加入某公司的资深高管，可能比一个只匹配职位标题过滤器的人更值得打。但这里有一个必须停下来做的区分：
换工作并不能证明这个人搬了家、涨了薪、或者打算买产品。它是一个更仔细研究这个人的理由，它不构成联系他的许可。
而加这一个信号之后，要跟着改的地方是一串：研究 agent 要验证新职位、标注来源、记录变更时间；打分 agent 要决定这个变化占多少权重、需要什么佐证；营销层要把它翻译成一个内部切入角度，同时不能把搬迁、薪酬或购买意图当成事实来推断；仪表盘要显示来源、分数、建议和审批状态；销售最后还要决定这个人值不值得接触、走哪个渠道、什么时候。
于是三个角色的手同时伸进了同一条工作流。每个人的贡献都有价值，但没有任何一条规则回答：谁能增删信号规则、谁判定证据是否足够新、谁批准营销角度、谁能改产品行为、谁允许触达继续往下走，以及——当这些指令彼此不匹配时，AI 该做什么。
二、根因：上下文不产生权限
作者最初把这当成一个上下文问题来解：把客户通话、信号规则、工作流规格、触达逻辑全部塞进 AI，给它整条链。
结果是 AI 变得更有见识，却依然没有权限。它能指出一条指令影响了另一条，能展示下游会发生什么变化，但它无法决定谁有权改那条规则。
问题的定位应该更精确一些。看起来相似的四种症状，需要四种完全不同的动作：
| 症状 | 该做的 |
|---|---|
| 任务不清楚 | 改 prompt |
| 证据缺失 | 去检索 |
| AI 访问不到记录 | 修集成 |
| 两条同样成立的角色指令冲突 | 指定决策所有者 |
更大的 prompt 只解决第一行。第四行需要的是一份运营协议。绝大多数团队卡住时的第一反应是把提示词写得更长、把知识库塞得更满，而这张表说明，四类问题里只有一类能被那个动作解决。
这也顺带修正了一个流行判断。过去两年反复被提到的动作是「让你的组织对 AI 可读」——把流程、口径、判断标准写下来，让模型能读懂。这件事是必要的，但它只解决「它知道什么」，完全不触及「谁说了算」。可读性和授权是两层，需要分别建。
三、Shared Agent Brief：一个共享 agent 需要的五样东西
作者把这份运营协议叫做 Shared Agent Brief（共享 agent 简报）。它由五个部分组成：
- SHARED OBJECTIVE 共同目标：团队必须反复产出什么结果？
- ROLE INPUTS 角色输入：每个人能贡献什么证据、建议、决定和批准？
- DECISION RIGHTS 决策权：每个决定由谁说了算？
- AI BOUNDARY AI 边界：AI 可以完成什么，必须在哪里停？
- DECISION RECORD 决策记录：AI 完成了什么、人决定了什么、工作流接下来进入什么状态？
缩写成一个公式：
共享 agent = 共同目标 + 角色输入 + 决策权 + AI 边界 + 决策记录
记忆给 AI 上下文。Shared Agent Brief 告诉它谁的决定统治这项工作。
落地按五个阶段推进，Choose → Brief → Test → Run → Review：
- Choose：挑一个反复发生、且有可观察完成状态的工作流
- Brief：定义证据、角色、决策权、允许的 AI 工作和停止条件
- Test：造两个案例，一个 AI 应该推进，一个 AI 应该扣住
- Run：一次只处理一个工作项
- Review：记录人的决定。只有当一个被复核过的结果证明它合理时，才改一条规则，然后重跑那两个测试
权限是后面的事，按阶梯放开：手动 → 只读 → 受控的内部写入。对外发送明确排除在第一个工作流之外。
这条阶梯里最容易被跳过的是「受控的内部写入」和「对外发送」之间那道墙。内部写入出错可以回滚，对外发送出错不能。把它们放在同一次授权里，等于用可回滚动作的风险水平给不可回滚动作定了价。
四、把「输入」和「权威」分开
真正的转折发生在作者不再把每一条发给 AI 的消息当成同一种指令之后。一条消息可能是四种东西之一：
| 类型 | 含义 |
|---|---|
| EVIDENCE 证据 | 发生了什么，信息从哪来 |
| RECOMMENDATION 建议 | 这个人认为应该发生什么 |
| DECISION 决定 | 简报分配给这个角色的那个决定 |
| APPROVAL 批准 | 现在被允许的那个具体动作 |
这四种消息在聊天框里看起来几乎一模一样，携带的权威却完全不同。一条消息还可能同时包含多种类型，AI 必须先把它们拆开，再套用简报。
这里有一个容易被忽略的媒介问题。在会议室里，一句话的分量可以从说话的人、语气、谁在场、谁没有反驳里读出来。在一条发给 agent 的消息里，实习生的猜测和 VP 的批准是同一种形状的文本。模型只好用别的线索去猜权威——最新的、最详细的、语气最确定的——而这三个标准和实际的决策权毫无关系。
三个角色的边界因此要写得很硬：
- 销售带回的客户上下文是证据和商业方向，它不构成对每一处下游系统改动的批准。
- AI 工作流负责人可以改研究什么、怎么打分、建什么观点，但打分决定不等于发起 campaign 的批准。agent 逻辑可以准备工作，它不拥有那个商业动作。
- 产品可以决定系统怎么存、怎么显示，但产品里出现「建议触达」这个状态，不代表销售批准了触达。产品状态和商业批准是两个独立的决定。
对应地，AI 被明确禁止做三件事：
它不能因为某个人销售经验更多，就判定他的消息推翻了打分规则。
它不能因为一条工作流指令更详细，就判定它推翻了一条产品约束。
它不能因为某个行为已经存在于产品里，就判定它现在就是商业政策。
一句话概括：贡献权和决策权是两回事。
由此得到一个可以立刻用起来的说话模板，成本几乎为零——只是要求每个人在消息前面多写四行：
Speaking as: SalesEvidence: 最近的客户对话显示，高管换工作和新招聘公告值得测试。Recommendation: 在下一组已批准的客户上测试。I own: 商业假设和销售反馈。I do not own: 打分改动、产品实现、对外发送。这个模板里最关键的是 I do not own 那一行，因为它是唯一一条主动放弃权力的声明。人在写「我拥有什么」时会自然扩张，写「我不拥有什么」时会被迫收缩，而 agent 需要的恰恰是后面那条边界。少了这个区分，四个合理的输入就会变成四条竞争指令；有了它，AI 能保留证据、把决定路由给具名的人，并在任何人都没批准过的动作前停住。
五、第一个工作流：交付一个可被检查的决策状态
选哪个工作流先做，作者给了八条打分标准：是否反复发生、有没有清晰触发器、能否定义可观察的完成状态、所需输入是否可得、是否有多个角色参与、能否指名人类决策所有者、AI 能否在不对外行动的前提下准备有用的内部工作、能否在三到五个工作项上手动测试。
他们选中的是「每周客户推进」。每周五，试点集里的每个客户都要有：当前证据摘要、一个建议的下一步或明确的复核状态、这个建议的理由、一个具名的人类决策所有者，以及一份 AI 做了什么和没做什么的清楚记录。
提问方式随之改变。原来的问法是「帮我们跑这个客户的 GTM」，改成了：
读已批准的客户证据和角色输入。返回当前客户状态、建议的下一步、谁拥有那个决定，以及工作流是否可以继续。
产品端展示的是同一个对象，字段包括：工作项、当前证据、角色输入、这些输入能否共存、决策所有者、AI 完成了什么、还需要哪个人的决定、什么动作被阻塞、恢复条件、下一个状态。
一个真实例子里，AI ACTION 那一栏是这么写的：
准备了证据摘要、触达前提和复核请求。没有发送消息，没有改动 CRM 的归属、阶段或抑制状态。
这里藏着整套方法最值钱的一句判断：
第一个有用的产出是一个决策状态，团队里每个人都能打开它、检查它。AI 自己做出的决定排在这之后。
产品不需要去解读一段很长的 AI 对话，销售不需要去查看 agent 逻辑才能理解为什么这个客户被推荐，AI 也不需要猜一个建议是不是同时等于行动许可。
字段表里有两个在别处很少见到、但应该被抄走的：BLOCKED ACTION（什么动作被阻塞） 和 RESUMPTION CONDITION（恢复条件）。大多数日志只记录「做了什么」，这套 schema 强制记录「什么没做、以及要满足什么才能做」。这是审计边界是否生效的唯一办法——只记录已发生的动作，你永远无法证明那条边界起过作用；记录下「我在这里停住了」，边界才成为可验证的东西。
顺带说，这也把「什么条件下你敢让 AI 自己跑」这个问题倒了过来。正确的顺序是先造一个可被检查的中间对象，让它跑一段时间，信任是它长出来的副产品。顺序颠倒过来，团队就会一直卡在「要不要放手」这个无法回答的问题上。关于责任为什么无法被自动化，可以参考 Agent 够聪明后，FDE 会消失吗。
六、两条约束：防住模型的默认行为
作者给的两条 prompt 约束，价值高于 prompt 本身：
不要发明缺失的政策或决策所有者，标记为 UNKNOWN。
不要把一个当前做法或一条提议中的规则，转换成一条已批准的政策。
第一条防的是：让模型画一张决策权地图，它一定会交给你一张完整、漂亮、每个格子都填满的地图，包括那些你从来没有指定过所有者的格子。产出看起来像治理，实质是虚构。模型的默认行为是把空白填满，而一份治理文档的价值恰恰在于哪里是空的。
第二条防的更隐蔽，也更常见：既成事实被洗成政策。产品里已经有了「建议触达」这个状态，于是它悄悄变成了商业政策——没有人批准过，它只是先存在了。这个失效模式不限于 AI，但 AI 会大幅加速它，因为模型会把上下文里读到的一切当成既定事实来推理。你上周随手写在文档里的一句猜测，两周后会以「根据既有规则」的口吻出现在它的输出里。
对应的动作是给团队所有输入贴标签，并要求任何长期积累的上下文文件在文本上区分它们：
EVIDENCE / CURRENT PRACTICE / PROPOSED RULE / DECISION / APPROVAL / UNKNOWN证据 / 当前做法 / 提议中的规则 / 决定 / 批准 / 未知这一条对个人的知识库同样成立。把猜测、现行做法、已批准规则混在同一份 markdown 里，模型迟早会把它们抹平成同一个可信度。
七、适用边界与三个常见误区
这套方法适用于：多人共同管理同一批 agent、且工作流中存在不可回滚动作（对外发送、改客户记录、支付、发布）的场景。如果只有一个人用 AI，且所有动作都可撤销，这份简报是过度设计。
误区一：把决策权的定义本身交给 AI 去做。 原文开头写着「如果你读不完，把它交给你的 agent 去实施」，但全文的核心论点正是：决策权不能被委托，尤其不能委托给一个会把提议自动转成政策的东西。AI 可以帮你整理成文档，不能替你决定谁说了算。
误区二：先追求覆盖面，再补规则。 正确顺序是先挑一个工作流、三到五个工作项、手动跑通、两个测试用例长期保留。把 AI 接进每一个流程，只会把冲突的数量乘上流程的数量。
误区三：把可读性当成终点。 把流程写下来让 AI 读懂，这是前置条件，终点还在后面。上下文喂到再饱和，agent 仍然不知道两个都成立的指令该听谁的。
还需要留一点余量：这是一个三人团队的实践记录，全文没有给出任何结果数据——没有错误率下降多少、处理量提升多少的对照。文中反复出现的 GTM 工具是该 newsletter 的合作方。所以这套框架的价值在于它对问题的定义和那些字段设计，把它当作一份待验证的方法论来用，别当成被数据证明过的方案。
小结
把 AI 接进多人协作的业务流程时，真正的瓶颈出现在授权层。上下文层堆得再厚，也补不上它。可以照着下面的顺序动手：
- 用四症状表定位：任务不清改 prompt，证据缺失去检索，访问不到修集成，指令冲突指定决策所有者。
- 挑一个反复发生、有可观察完成状态、多角色参与的工作流作为起点。
- 写出五要素简报：共同目标、角色输入、决策权、AI 边界、决策记录。
- 给每条输入加上
Speaking as / I own / I do not own前缀，并把六类标签用进所有长期上下文文件。 - 让 AI 交付的第一个产物是可检查的决策状态，包含「什么被阻塞」和「恢复条件」两个字段。
- 权限按手动 → 只读 → 受控内部写入的阶梯放开，对外发送单独授权。
关于如何把 AI 从「派任务」升级为「交一份带持续期待的工作」，可以接着读 如何把 AI 装进现有生意：从派任务到交工作；关于多 agent 协作本身的结构选型，见 Multi-Agent 工作流的 6 种模式与选型指南。