Agent Team 先在代码工具里规模化：几个具名 Agent 通过共享上下文和任务流，在同一份代码库上协作。同一套结构也适用于代码评审之外的任何需要人负责的重复性工作，例如研究、起草和审阅。本文说明 Agent Team 成立需要什么条件、与子 Agent 有什么区别，以及团队如何开始引入。
Agent Team 成立的三个条件：成员共享同一份上下文、每件任务有具名负责人、每件交付物经人验收后才计入结果。
快速结论
Agent Team 是一组围绕一个持续性工作、各有明确角色的 AI Agent。它们共享同一份上下文，通过负责人明确的任务交接工作，每件交付物在计入结果之前由人验收。与单个 Agent 聊天式用法的区别，是工作单位从消息变成了任务和交付物。人的职责不变：设定目标、界定边界、验收结果。
什么是 Agent Team
Agent Team 是一组围绕一个持续性工作分工的 AI Agent。研究 Agent、起草 Agent、审阅 Agent，当它们进入同一个频道、读取同一份上下文、通过任务互相交接时，就构成一支团队。人负责设定目标并负责最终验收。
代码工具里的 Agent Team
在 Claude Code 这类代码工具里，Agent Team 是一组独立的 Agent 实例，在同一份代码库上并行运行，共享一张任务清单并直接通信；team lead 可以拆分工作并合并结果。共享上下文就是仓库状态和任务清单。
这个结构适合处理单一代码库、单次会话。边界在于团队存在于工具内部：参与审阅的人就是这次会话里的开发者，产出是代码，在常见设计中，除非显式导出，记录不会比会话更长。
在工作空间中运行的 Agent Team 有三个可以核实的区别。第一，团队跨会话、跨人工作，上下文持续积累，不会每次清零。第二，产出是人在工具之外可以打开并验收的交付物。第三，需要人工确认的操作由 Agent 起草请求，在工作空间中形成动作卡（Action Card），再由有权限的人以本人身份确认并执行。代码工具里的 Agent Team 与工作空间里的 Agent Team 共享同一个模式；在工作空间中运行的 Agent Team 多了记录、交付物和人工确认环节。
Agent Team 和子 Agent 的区别
子 Agent 是更简单的模式：一个主 Agent 为边界明确的子任务临时启动若干子 Agent，收集结果后并入自己的回答。在常见的 parent-child 设计中，临时子 Agent 没有独立身份，在工作空间中没有位置，运行结束后也不保留记录。Agent Team 不同：成员具名，有角色、有自己的访问权限，上下文跨会话保留，产出成为人可以审阅的交付物。
两种模式回答的问题不同。子 Agent 减少单次运行中的直接协调负担：一个编码 Agent 把大任务拆成并行步骤，人不必逐个照看。Agent Team 回答的是协调问题：哪个具名 Agent 负责研究、哪个负责起草、哪个负责审阅、谁决定工作何时完成。子 Agent 是否让单个 Agent 更快，需要团队实测；Agent Team 让分工和责任可追溯。
当工作需要审阅、归属和可复核的记录时，子 Agent 模式到达它的边界：帮手完成后，结果落进一条消息，记录随运行结束。这正是工作需要一个具名、交付物可见的团队的时刻。
三个特性把 Agent Team 和一组独立的对话工具区别开。
具名角色。 每个 Agent 有一份职责说明、一套工具和一个边界。它的产出可以对照角色评估，不必把整个任务逐项比对。
共享上下文。 团队读写同一批消息、文件和决定，不依赖某个 Agent 才能看到的私人提示词。
可见的工作流。 工作通过有状态的任务流动。哪些已完成、哪些在等待、每步由谁负责，一眼可见。
话题和团队的区别
话题和团队的区别是工作结构的区别，当信息必须形成可追责的交接时才变得重要。只有一个共享 Agent 的话题是一场对话：消息滚动，下一步没有具名负责人，没有可审的交付物，也没有谁决定了什么的记录。话题本身适合对话；对需要跨角色重复交接的交付物，单靠话题不足以形成责任与记录。
Agent Team 提供归属与记录，而话题只是一场对话。区别在结构上可见：频道保留共同简报和决策历史，具名任务显示每步的负责人和状态，交付物是评审者打开并评估的对象。
Agent Team 需要什么条件
四个条件成立时，Agent Team 才是适用的协作方式：共享上下文、负责人明确的任务、可审的交付物、人工确认环节。
共享上下文。 团队需要一份比任何单次对话都持久的上下文。一个持续积累目标、约束、决定和链接的频道，让团队内的 Agent 每天从同一份起点出发。
负责人明确的任务。 每件工作都有负责人和状态。遇到阻塞时，团队可以指向一条任务，说出由谁负责。
可审的交付物。 Agent 交回的是草稿、表格、报告、来源清单这类交付物。聊天消息记录进展，交付物是评审者打开并评估的对象。人审阅的是交付物本身。
人工确认环节。 团队设定目标和验收标准，并指定哪些操作需要人工确认。对这些操作，Agent 起草请求并形成动作卡，再由有权限的人以本人身份确认并执行。人工确认环节也让记录写明每件交付物由谁验收，团队日后可以复核。
如何维护共享上下文
共享上下文听起来抽象，直到一队 Agent 开始并行工作。机制本身很具体：团队写进同一个频道，决定落在频道成员与获准访问的 Agent 都能读的消息里，文件和草稿挂在记录上，任务指向同一个目标。Agent 认领任务时先读上下文，完成后把结果发回团队可见的位置。
检验共享上下文的方法：问一句上周二那个决定现在在哪里。如果它在团队成员和 Agent 都获准访问的频道里，上下文就是共享的；如果它在一段私人提示词或单次对话里，就没有共享。把决定放进同一份共享记录的团队，很少对同一件事出现两种理解，因为「当时是怎么定的」的答案是消息，不是记忆。
两个习惯能让上下文保持干净。第一，把目标和验收标准写进频道，而不是写进临时说明。第二，目标变化时更新共享记录，让参与工作的 Agent 从记录里读到变化，而不是逐个私聊。
Syfo 如何支持 Agent Team
当任务状态、最新约束和交接记录分散在零散消息和私人提示词里时，没有人能判断哪份信息是当前的、下一步由谁负责，或哪些动作仍需要人工审阅并提交。
Syfo 与 Agent Team 的关系
Agent Team 是一种协作结构：具名角色、依赖交接和审阅。Syfo 是让人和 Agent 共同工作的工作空间，承载团队选择的协作与验收层：频道保存共同简报与决策记录，任务板显示每件任务的负责人与状态，交付物供人打开复核；需要人工确认的操作由 Agent 起草请求并形成动作卡，再由有权限的人以本人身份确认并执行。
这让团队可以在同一工作空间中查看并核验角色与交接：谁做了什么、什么被验收、哪项操作由谁确认。
Syfo 不替团队选择协作模型，也不设计角色、目标、权限、风险策略、安全控制、运行时编排或业务决策，更不是编排框架；Agent Team 如何组织、人工确认环节放在哪里，仍由团队决定。
这一结构的组织模式是 Organizational Agent Harness；实际运行这一模式的团队，可以自行查看 Syfo 案例页（供读者查阅，不构成效果证明）。
一个例子
每周研究简报可以说明这个模式。团队负责人在频道里发布简报要求：主题、可信来源、格式、截止时间。研究 Agent 收集并整理来源，写入共享文档。起草 Agent 把笔记变成结构化的简报。审阅 Agent 对照要求检查事实、链接和语气。人阅读最终交付物，提出修改；需要人工确认的操作，由人以本人身份确认并执行。
Agent 审阅和人工验收是两步。审阅 Agent 在人看到之前先发现问题，最终决定仍然由人做出。每一步都留在共享记录里。一周之后，团队可以看到哪个 Agent 写了什么、审阅后改了什么、谁验收了最终版。
Agent Team 常见的失效模式
Agent Team 的失效模式值得逐一说明，因为每一种都对应一个可修复的结构问题。最常见的是上下文孤岛：成员各自记录，共享频道逐渐安静，团队朝不同的目标并行漂移。修复方式是结构性的：让频道成为决定落地的固定位置，让任务指向共享记录。
第二种是审阅瓶颈。交付物产出快于人工审阅速度时，团队停在人工确认环节，队列成为真正的约束。解决方式是缩小交付物、先由审阅 Agent 过滤问题，让人在最合适的粒度上把关。
第三种是归属模糊。任务没有具名负责人时，成员会以为别人会接手。修复方式是立一条规则：每件任务恰好一个负责人，每件交付物写明是哪个 Agent 产出的、由哪个人验收。
什么仍然留给人
Agent Team 承担的是并行、可重复、可验收的那部分工作：收集来源、起草、核对事实。设定目标、守住边界、接受结果，这些仍然是人。需要判断、Agent 不被授权做出的决定，也仍然是人。团队扩大了小团队能交付的范围，责任始终在人身上。
团队如何开始引入 Agent Team
- 团队负责人挑一件团队已经在产的重复交付物，例如摘要、报告或简报。
- 团队负责人在频道里写下目标和验收标准，列出需要的角色。
- 团队负责人或 Agent 在任务板上创建具名任务并指定负责人。
- Agent 更新自己的任务，把可打开的交付物交回频道。
- 审阅 Agent 在任何人宣布成品之前检查工作。
- 需要人工确认的操作由 Agent 起草请求，再由有权限的人以本人身份确认并执行。
从比实际需要更小的规模开始。两个 Agent 加一件清楚的交付物，团队可以验证从任务创建到人工验收的完整流程；五个 Agent 加一个模糊的目标无法验证。当审阅步骤成为固定环节，团队才进入预期的运行节奏。
首次试点验收。 扩大之前，团队应能回答四个问题：每件任务由谁负责、最新决定依据什么、每份交付物在哪里、由谁验收。答不上来的部分，先补齐记录和责任分工，再扩大团队。
如何选择协作方式
选择哪种协作方式取决于工作结构，而不是可用 Agent 的数量。单个 Agent 加人工复核，适合短小、单一上下文的任务：一个 Agent 加一份清晰的简报可能更快、成本更低，但需要团队实测确认，也更便于审阅。顺序型工作流加具名交接，适合必须按序推进的工作，每一步依赖前一步的产出，且每次交接都有负责人。小型 Agent Team 加明确的人工确认环节，适合角色数量有限、角色固定、交接或审阅相互依赖的工作：每个步骤都有具名负责人，需要人工确认的操作由有权限的人确认并执行。Agent swarm 适合大量并行、松耦合、可以独立推进的子任务：子任务之间不等待彼此的产出，共享同一份记录即可。团队形式让角色和交接保持可读，swarm 形式让大量独立子任务在没有中央控制器逐级分派任务的情况下扩展。
当工作存在产出、审阅、验收等明确角色，且产出需要在记录里保持可复核时，Agent Team 是合适的单位。新增 Agent 前，先明确需要补充的角色。两个 Agent 加一轮审阅，每件交付物在宣布成品前都会被检查；五个 Agent 没有审阅则无法保证。如果团队说不出新 Agent 扮演什么角色，就还不需要这个 Agent。
FAQ
什么是 Agent Team？
Agent Team 是一组有具名角色的 AI Agent，共享一份上下文，通过任务互相交接，由人负责设定目标并审阅交付物。
Agent Team 和子 Agent 有什么区别？
子 Agent 是主 Agent 为边界明确的子任务临时启动的子 Agent，完成后并入自己的回答，没有独立身份和记录。Agent Team 是常驻的具名成员，有角色、共享上下文和可见的交付物。子 Agent 是否让一个 Agent 更快，需要团队实测；Agent Team 让分工和责任可追溯、可审阅。
Agent Team 和多智能体系统有什么区别？
多智能体系统是技术分类。Agent Team 是按真实工作的组织方式落地这个分类：角色、负责人明确的任务、共享上下文、人工把关，都在同一个工作空间里。
Agent Team 交付工作，谁负责？
人负责。人设定目标，对需要人工确认的操作以本人身份确认并执行，接受或退回结果。任务和交付物让责任看得见，最终责任仍由人承担。
Claude Code 里的 Agent Team 是什么？
Claude Code Agent Team 是一组独立的 Agent 实例，在同一份代码库上并行运行，共享一张任务清单并直接通信。它们解决的是单次会话内的并行编码；在工作空间中运行的 Agent Team 多了跨会话上下文、人可打开的交付物，以及需要人工确认的操作所对应的动作卡。
Agent Team 能没有人类负责人吗？
很多步骤可以自行运行，目标、边界和最终验收仍然由人决定。工作空间把决定、交付物验收和人工确认的操作记录下来，责任看得见，不需要靠信任维持。
如何组建 Agent Team？
挑一件重复交付物，在频道里写下目标和验收标准，按需要的角色加入 Agent，让工作通过任务流动，需要人工确认的操作形成动作卡，再由有权限的人以本人身份确认并执行。
可追责的团队
Agent Team 在工作的可见程度足够时才算有效：具名角色、一份共享上下文、负责人明确的任务、每件交付物由人验收。从两个 Agent 和一件重复交付物开始，运行到审阅步骤成为固定环节，让频道、话题和任务板中的记录持续可查。能够规模化的团队，是那个对结果负责的人随时能看到谁做了什么、每件交付物由谁验收的团队。