群组 Agent 不是玄学：把 Team Agent 的三个判据拆成四个能落地的组件（飞书原型代码）

最近一篇讲 Team Agent 的文章在圈里传得很广，核心观点是：个人 AI 再强也救不了组织低效，下一个风口是"群组 Agent"——不是群里加个聊天机器人，而是能持续跟踪任务、主动推进、维护团队工作状态的 Agent。

文章写得很好，但停在"产品应该长什么样"。这篇做另一半：把它的判据拆成工程问题，逐条回答"这周能在飞书群里搭出什么"。能搭的给代码，搭不了的明确说为什么。

一、先立三个判据（从概念文章提炼，可检验）

那篇文章判断"是不是真 Team Agent"用了三个问题，我把它工程化：

文章里最值钱的一句：「群聊中有人说’这个方案可以考虑’，不能自动变成已经批准。」——这是判据③的核心，也是 90% 的"群机器人"产品没做的事。

结论：Team Agent 和群聊机器人的分界线，不是会不会聊天，是有没有一套"持续更新、被团队认可的工作状态"。

二、四个能落地的组件（飞书原型）

把三个判据映射到四个组件，全部用本系列前几课的现成能力拼：

组件 A：状态表——"尚未兑现的工作承诺"存哪

文章说 Team Agent 管理的是"团队所有尚未兑现的工作承诺"。落到飞书，就是一张多维表格，字段设计直接决定后面一切：

为什么"证据"字段不能省：文章强调"任何状态变化，都有对应的证据或确认"。没有证据列，三个月后没人记得这条"已授权"是谁批的。

组件 B：三级识别——讨论 ≠ 决定 ≠ 授权

这是最难也最关键的一步。用提示词让 AI 从群消息里判断"这句话是哪一级"：

你是团队工作状态识别器。读一条群消息，判断它属于哪一级，只输出 JSON：
{"level": "discussion|decision|authorization|none", "task_ref": "提到的任务或null", "reason": "一句话依据"}

分级规则：
– discussion：提出想法、询问、建议、"可以考虑"、"我觉得"——不改变任何状态
– decision：明确结论、"定了"、"就按X做"、会议纪要中的决议——可把状态从 讨论中→待批准
– authorization：有权限的人明确授权执行、"批准"、"同意开工"、"预算OK去做"——可把状态从 待批准→已授权
– none：闲聊、与任务无关

铁律：
1. 拿不准就输出 none，宁可漏判不可错判（错判会把闲聊变成"已批准"）
2. authorization 必须能指出授权人；指不出就降为 decision
3. 不推测消息里没有的信息

两条铁律是防事故设计：漏判无害（状态不动），错判有害（闲聊变批准）。所以阈值必须偏向保守。

组件 C：跟进引擎——"主动"不等于定时发提醒

文章批评得很准：「真正的主动性，不是每天定时总结、发几条提醒。」跟进引擎做两件事：

巡检规则（写死在代码里，不交给模型自由发挥）：
– 只巡检 状态=已授权/进行中 且 更新时间 < now-48h 的行
– 依赖字段非空 → 先发"依赖未满足"卡片给依赖方，不催负责人
– 同一任务 24h 内只催一次（用 催办时间 字段去重）
– 每天最多发 3 张催办卡（防刷屏，L6 讲过的群体验）

组件 D：状态机——防重复执行与状态冲突

文章点名的两个事故：「一个任务已经由员工完成，Agent 不能再次执行；一个报价已经被财务修改，另一个 Agent 不能拿旧版本继续提交。」用状态机 + 版本号解决：

"""Team Agent 原型核心：状态机 + 版本防冲突 + 三级识别接入点。纯逻辑，可单测。"""
from datetime import datetime, timedelta

# 合法状态迁移表（写死，模型无权改）
TRANSITIONS = {
"讨论中": {"待批准"}, # 仅 decision 级消息可触发
"待批准": {"已授权", "讨论中"}, # authorization 可批准；新讨论可打回
"已授权": {"进行中", "被阻塞"},
"进行中": {"待验收", "被阻塞"},
"被阻塞": {"进行中"}, # 依赖满足后恢复
"待验收": {"完成", "进行中"}, # 验收不过打回
"完成": set(), # 终态，不可再动
}

# 每级迁移需要的消息级别（组件B的输出）
LEVEL_REQUIRED = {
("讨论中", "待批准"): "decision",
("待批准", "已授权"): "authorization",
}

class StateError(Exception):
pass

def apply_change(task, new_status, level, actor, evidence_url, now=None):
"""尝试更新任务状态。task 是状态表一行的 dict（含 状态/版本/负责人）。
返回 (是否更新, 原因)。所有拒绝都带原因，写进审计日志。"""
now = now or datetime.now()
cur = task["状态"]

# 闸1：终态不可动（防"已完成又被Agent重跑"）
if cur == "完成":
return False, "任务已完成（终态），拒绝变更"

# 闸2：迁移合法性（状态机写死）
if new_status not in TRANSITIONS.get(cur, set()):
return False, f"非法迁移 {cur}→{new_status}"

# 闸3：级别匹配（discussion 不能批准，decision 不能授权）
need = LEVEL_REQUIRED.get((cur, new_status))
if need and level != need:
return False, f"{cur}→{new_status} 需要 {need} 级消息，实际 {level} 级"

# 闸4：授权必须指名授权人，且不能是任务负责人自己批自己
if new_status == "已授权":
if not actor:
return False, "authorization 缺少授权人"
if actor == task["负责人"]:
return False, "负责人不能自批授权"

# 闸5：版本乐观锁（防"拿旧报价继续提交"）
# 调用方需传入读到的版本；这里用 task["版本"] 自增模拟
task["状态"] = new_status
task["版本"] = task.get("版本", 0) + 1
task["证据"] = evidence_url
task["更新时间"] = now
return True, f"{cur}→{new_status} by {actor or level}"

def need_nudge(task, now=None, stale_hours=48):
"""巡检：该不该催。返回 (是否催, 催谁, 原因)。"""
now = now or datetime.now()
if task["状态"] not in ("已授权", "进行中"):
return False, None, "状态不在巡检范围"
updated = task.get("更新时间") or now
if now – updated < timedelta(hours=stale_hours):
return False, None, "未超48小时"
if task.get("依赖"):
return True, "依赖方", f"依赖未满足：{task['依赖']}"
last_nudge = task.get("催办时间")
if last_nudge and now – last_nudge < timedelta(hours=24):
return False, None, "24小时内已催过"
stale = int((now – updated).total_seconds() // 3600)
return True, task["负责人"], f"{task['状态']} 已 {stale}+ 小时无更新"

if __name__ == "__main__":
t = {"task_id": "T-001", "任务": "对接支付回调", "负责人": "张三",
"状态": "讨论中", "依赖": "", "版本": 0}
# 闸2演示：讨论中直接跳已授权（非法迁移）→ 拒
ok, why = apply_change(dict(t), "已授权", "discussion", "李四", "https://msg/1")
print("越级迁移:", ok, "|", why)
# 闸3演示：待批准→已授权 但消息只是 discussion 级 → 拒
t_disc = dict(t, 状态="待批准")
ok0, w0 = apply_change(t_disc, "已授权", "discussion", "李四", "https://msg/1b")
print("讨论级想批准:", ok0, "|", w0)
# 正常链路：decision 进待批准 → authorization 进已授权
ok1, w1 = apply_change(t, "待批准", "decision", None, "https://msg/2")
ok2, w2 = apply_change(t, "已授权", "authorization", "李四", "https://msg/3")
print("decision→待批准:", ok1, w1, "| authorization→已授权:", ok2, w2)
# 闸4演示：自批 → 拒
t2 = dict(t, 状态="待批准", 负责人="李四")
ok3, w3 = apply_change(t2, "已授权", "authorization", "李四", "https://msg/4")
print("负责人自批:", ok3, "|", w3)
# 闸1演示：完成后再动 → 拒
t3 = dict(t, 状态="完成")
ok4, w4 = apply_change(t3, "进行中", "authorization", "李四", "https://msg/5")
print("终态再变更:", ok4, "|", w4)

实测输出（五道闸全部生效）：

越级迁移: False | 非法迁移 讨论中→已授权
讨论级想批准: False | 待批准→已授权 需要 authorization 级消息，实际 discussion 级
decision→待批准: True 讨论中→待批准 by decision | authorization→已授权: True 待批准→已授权 by 李四
负责人自批: False | 负责人不能自批授权
终态再变更: False | 任务已完成（终态），拒绝变更

结论：状态机五道闸——终态不可动、迁移白名单、级别匹配、授权指名且禁自批、版本乐观锁。模型只负责判级，无权改规则。

三、三段编排提示词（状态识别之外的角色）

① 会议 → 决定/行动项结构化——提示岛 id=1836（3214 字）核心段：

Summarize the meeting transcript by performing the following tasks:

– **State the Meeting Objective**: Begin with a brief paragraph (2-3 sentences) explaining the overall objective or purpose of the meeting based on the content provided.
– **Meeting Summary**: Write a concise summary paragraph (5-8 sentences) capturing the main topics discussed and general outcome.
– **Meeting Title**: Create a clear and descriptive title for the meeting.
– **Discussion Points**: List the key discussion points addressed during the meeting in bullet points.
– **Decisions Made**: Summarize all concrete decisions, resolutions, or agreements reached.
– **Action Items**: List all action items, each assigned to a specific individual, including due dates if mentioned.

为什么它适合组件 B 的上游：输出结构里 Decisions Made 和 Action Items（assigned to a specific individual, including due dates） 正好对应状态表的"决定"和"负责人+截止"——会议纪要跑一遍这个提示词，产物直接灌状态表，比让机器人实时听群消息稳得多（会议是决定最密集的场景）。

② 多 Agent 编排纪律——提示岛 id=2014（4462 字）核心段：

– Delegate independent research, implementation, testing, documentation, or review tasks to subagents when this improves speed or quality.
– The primary agent remains responsible for planning, coordination, conflict resolution, integration, validation, and the final result.
– Do not require me to manually coordinate subagents.
– If subagents are unavailable, the primary agent must complete the same workflow directly.
– Do not split dependent work across uncoordinated agents.
– Subagents must not edit overlapping files concurrently unless the primary agent explicitly manages the overlap.

三条纪律直接抄进你的群组 Agent：主 Agent 对集成和验证负全责（出了错有人兜底）、依赖任务不许拆给无协调的 Agent（拆了就是状态冲突）、子 Agent 不许并发改同一份东西（除非主 Agent 显式管重叠）——这就是文章说的"多人多 Agent 同时行动时维持一致状态"的工程版。

③ 路由编排 JSON——提示岛 id=5126（CC0-1.0，1836 字）核心结构：

{
"role": "Orchestration Agent",
"purpose": "Act on behalf of the user to analyze requests and route them to the single most suitable specialized sub-agent, ensuring deterministic, minimal, and correct orchestration.",
"supervisors": [
{ "name": "TestCaseUserStoryBRDSupervisor",
"sub-agents": ["BRDGeneratorAgent", "GenerateTestCasesAgent", "GenerateUserStoryAgent"] },
…
]
}

值得学的是 route to the single most suitable——一次只路由给一个最合适的子 Agent，不是广播给所有。群组 Agent 里"谁接这个任务"必须唯一，否则就是重复执行。

结论：编排提示词三件套——纪要结构化灌状态表、主Agent负全责的编排纪律、单路由不广播。三段都可在提示岛一键复制（id=1836/2014/5126）。

四、诚实边界：现在做不了的三件事

结论：原型能覆盖"状态维护+跟进催办+防冲突"，覆盖不了"跨系统权威+经验升级+无人执行"——后者是产品级投入，不是教程级。

五、这套原型和 L7 多机器人讨论的关系

L7 是讨论型群组 Agent（六顶帽子各抒己见，产出是观点）；本课是状态型群组 Agent（维护工作承诺，产出是推进）。两者共用 L4 事件订阅和 L3 卡片，但核心不同：

文章说 Team Agent「最重要的产出是不断减少的未完成事项」——状态型才是 Team Agent 的本体，讨论型只是它的一个子能力。

六、弹药与入口

三段提示词来自提示岛（prompts.ssjintaitong.com）：站内多智能体/编排方向实测有 skill 类上百条（如 id=8839 DSH 多智能体编排插件 MIT、id=6311 多智能体编排模式插件 MIT、id=8081 高智议会多智能体插件 MIT，均附 GitHub 源）、text 类含 id=2014/5126 等编排提示词。全站收录超万条，文字提示词 3485 条，75% 标来源链接、68% 标许可证。免登录可复制。

• 本文三段提示词：prompts.ssjintaitong.com/prompts/1836、/prompts/2014、/prompts/5126
• 多智能体插件：站内搜「多智能体」（数十条 skill）、「orchestr」（上百条）
• 本系列前课：L4 事件订阅 / L5 多维表格 / L7 多机器人讨论（企业 AI 集成专题内）：prompts.ssjintaitong.com/topic/enterprise-ai-integration
• Skill 质量评分：prompts.ssjintaitong.com/quality-report

概念判据引自公开 Team Agent 分析文章（微信公众号"哈AI/小哈公社"2026-10-27《下一个风口：Team Agent》，其中 Shopify River 数据为该文引用，我方未独立核实其原始出处，标注为转引）；三段提示词全文摘自提示岛站内条目 id=1836/2014/5126，未修改，通过注入检测；状态机代码实测跑通（五道闸验证见第二节输出）；站点数据 2026-11-01 实测。