Copilot进Teams后，Agent协作不该只剩聊天记录

一个 Agent 任务如果持续 20 分钟，参与者有 5 个人，期间改了 8 个文件、跑了 3 轮测试、请求了一次审批，最后只把这些信息折叠成几十条聊天消息，协作成本其实并没有消失，只是从“做事”转移成了“翻记录”。

GitHub 在 8 月 21 日把 Copilot Cloud Agent 的共享会话带进 Microsoft Teams：频道、线程和私聊里可以直接 @GitHub 发起 Agent Session，参与者能补充上下文、追问、共同引导；拥有仓库写权限的人还能触发代码修改。Agent 在云端沙箱异步工作，进度继续回到 Teams 线程里，生成的 Artifact 又可以转到终端、Copilot App 或 IDE 继续处理。

真正值得研究的不是“Copilot 多了一个入口”，而是：多人共同驱动一个 Agent Run 时，哪些东西应该进入聊天，哪些东西必须成为结构化状态？

聊天适合表达意图，不适合承载整个 Run

群里的一句话：

@GitHub 帮忙查一下订单服务最近 401 增加的原因，
先不要改生产配置。

这里至少包含四个字段：

Goal: 定位 401 增加原因
Scope: 订单服务
Constraint: 不能修改生产配置
Initiator: 当前用户

如果 Agent 只保存原始自然语言，后续任何人补一句“顺便把配置改了吧”，就会出现约束冲突。所以群聊消息进入 Agent 之前，应该先投影成 Run Contract。

public record RunContract(
        String runId,
        String goal,
        Set scopes,
        Set constraints,
        String initiatedBy,
        Instant createdAt,
        long version) {
}

每次关键约束变化都形成新版本，而不是覆盖第一条消息。

共同引导，不等于所有人权限相同

GitHub 当前的 Teams 预览有一个重要边界：参与者都可以参与讨论和补充上下文，但真正触发仓库修改，还要求用户拥有对应仓库写权限。

多人协作至少应该拆成三类权限：

VIEW
STEER
MUTATE

更细可以定义：

public enum SessionPermission {
    VIEW,
    ADD_CONTEXT,
    STEER,
    APPROVE,
    EXECUTE_WRITE,
    CANCEL
}

同一个频道里，产品经理可以补充需求，QA 可以补测试条件，研发可以批准代码修改，普通观察者只能查看，只有 Run Owner 能 Cancel。

不要把“在群里能看到线程”直接等同于“可以让 Agent 做任何事”。

第一个真实故障模式：多人指令竞争

假设线程变成：

10:05 张三：只查原因，不改代码
10:07 李四：如果确定是超时，就顺手修掉
10:08 王五：今天不要碰支付模块
10:09 张三：先跑测试

模型看到的是四条自然语言。

执行系统真正需要的是：

Constraint Set
Action Policy
Authority
Version

例如：

{
  "run_id": "run-812",
  "goal": "diagnose-401",
  "constraints": [
    "no-production-config-change",
    "do-not-touch-payment-module"
  ],
  "allowed_actions": [
    "read-code",
    "run-tests",
    "create-patch"
  ],
  "forbidden_actions": [
    "merge",
    "deploy"
  ]
}

任何后续消息如果试图删除 forbidden_actions，必须重新做权限判断。不能让模型按“最近一句话优先”自行覆盖约束。

第二个故障模式：线程越长，真正重要的信息越少

多人讨论很容易积累：

需求说明
日志
猜测
截图
会议结论
代码片段
重复追问

把整个 Teams Thread 每轮都喂给模型，Token 会持续上涨，历史噪声也会越来越多。

更合理的链路是：

聊天原始记录
↓
Event Store
↓
Current Run Projection
↓
Task Context Manifest
↓
LLM

真正给 Agent 的 Manifest 只保留当前有效状态：

{
  "goal": "diagnose-401",
  "constraints": [
    "no-production-config-change"
  ],
  "current_hypotheses": [
    "JWT refresh race",
    "gateway timeout"
  ],
  "verified_facts": [
    "error started after release-1842"
  ],
  "artifacts": [
    "trace-91",
    "log-sample-17"
  ],
  "pending_decisions": [
    "allow-source-code-change"
  ]
}

聊天是证据源，Projection 才是执行状态。

第三个故障模式：所有人都以为“别人已经看过”

Agent 改完代码后，群里出现一句：

Patch ready.

团队很容易出现一种心理：

应该有人看了吧。

最后没人真正 Review。

所以需要显式 Review Gate：

public record ReviewGate(
        String artifactId,
        Set requiredReviewerRoles,
        Set approvedBy,
        ReviewStatus status) {
}

例如：

代码 Patch：Backend Owner
数据库 Migration：DBA + Backend Owner
权限变化：Security

“群里没人反对”不能替代批准。

Teams 只是入口，Source of Truth 应该在服务端

GitHub 的共享 Agent 设计允许任务在 Cloud Sandbox 中异步执行，即使用户离开当前界面，任务仍然继续；不同界面可以继续接手同一任务产生的 Artifact。

这意味着真正的 Run State 必须在服务端：

Teams
IDE
CLI
Web

只是客户端。

服务端维护：

Run
Thread
Turn
Artifact
Approval
Budget
Audit

否则 Teams 消息删除、客户端断线、用户换设备后，Agent Run 就无法正确恢复。

一个最小 Run Event 模型

public sealed interface RunEvent
        permits RunCreated,
                ContextAdded,
                ConstraintChanged,
                StepStarted,
                ArtifactCreated,
                ApprovalRequested,
                ApprovalGranted,
                RunCompleted {
}

事件示例：

{
  "event_id": "evt-912",
  "run_id": "run-812",
  "type": "CONSTRAINT_CHANGED",
  "actor": "user-17",
  "payload": {
    "add": ["do-not-touch-payment-module"]
  },
  "occurred_at": "2026-08-23T10:08:22Z"
}

Teams UI 只负责把事件渲染成易读消息。

“谁说了算”必须是确定性规则

可以设计权限层级：

Security Policy
>
Run Owner
>
Repository Owner
>
Contributor
>
Viewer

但真正执行应该由 Policy Engine 判定，而不是塞进 Prompt。

public Decision evaluate(
        Participant participant,
        RequestedMutation mutation,
        RunContract contract) {

    if (!participant.permissions()
            .contains(mutation.requiredPermission())) {
        return Decision.DENY;
    }

    if (mutation.conflictsWith(contract.constraints())) {
        return Decision.REQUIRE_OVERRIDE_APPROVAL;
    }

    return Decision.ALLOW;
}

LLM 负责理解意图，不能负责最终授权。

共享会话有一个很实际的问题：成本可能比私聊更高

GitHub 说明里明确提到，Teams 中发起的 Cloud Agent Session 会消耗 AI Credits；Cloud Sandbox 使用又可以单独计费和配置预算。

多人 Steering 会增加：

上下文
Turn 数
重新规划次数
测试次数

所以群聊 Agent 最好直接展示：

Current Cost
Budget
Model Calls
Sandbox Minutes

例如：

AI Credits：31 / 50
Sandbox：18 min / 30 min
Model Calls：12

有人说“再从另一个方向全部查一遍”时，团队能知道这不是零成本操作。

Steering 也需要预算

collaboration:
  max_steering_turns: 12
  max_context_additions: 30
  max_replans: 4

达到阈值后：

继续执行需要 Run Owner 确认

避免讨论无限延长 Agent Run。

Agent 产出必须从消息升级成 Artifact

代码修改：

Patch Artifact

测试：

Test Report Artifact

调查结论：

Incident Findings Artifact

对象模型：

public record Artifact(
        String artifactId,
        ArtifactType type,
        String version,
        String contentRef,
        String contentHash,
        String createdByStep,
        ArtifactStatus status) {
}

Teams、IDE、Web 都引用同一个 Artifact，而不是各自复制一份文本。

我会只在 Teams 里固定展示 5 类卡片

1. Goal
2. Progress
3. Artifact
4. Decision Needed
5. Final Result

例如：

[Decision Needed]

Agent:
order-incident-agent

Action:
修改 JwtRefreshService.java

Reason:
复现到并发刷新竞争

Evidence:
test-run-912

Risk:
MEDIUM

[Approve Patch] [Keep Investigating]

比一句“我已经分析了问题，接下来建议……”有用得多。

共享讨论不能直接写入长期 Memory

频道里会出现猜测、玩笑和未经确认的信息。

至少区分：

Conversation Context
Run State
Verified Fact
Long-term Memory

只有经过确认的事实才能进入长期 Memory。

例如：

订单服务使用 JWT

可以。

我觉得一定是 Redis

不能。

GitHub 把 Copilot Agent 拉进 Teams，表面看是入口扩展，真正重要的是它让一个问题无法再回避：Agent 不再只有一个用户。

多人共同指导时，聊天记录只能是输入界面，不能再充当执行系统本身。

生产级协作 Agent 至少需要：

Run Contract
Participant Permission
State Projection
Artifact
Approval
Budget
Audit

否则群里越多人参与，Agent 的上下文越丰富，系统反而越难回答最基本的问题：

现在到底要做什么？
谁允许改？
哪个结果已经确认？
下一步由谁决定？

这才是多人 Agent 协作真正的工程边界。

更多企业级 AI 应用、Agent、RAG 与大模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/