一个AI代理够用，为什么还要组一个团队？

周二早上7:40，Priya有一个问题，她的主管要在午饭前拿到答案：四天工作制到底能不能保住生产力？她本可以把问题粘进聊天机器人，换回一段语气笃定的文字。但找出数字的是同一个模型，判断这些数字站不站得住的也是它，而它很少会反驳自己。

她要的是分工：一个人去找实验，一个人去抽数据，再一个人把没有来源的内容全部打回去。这正是 osFoundry 里 Agent 与 Agent team 两种入口要解决的事。

osFoundry 是一款在本地机器上跑 AI 工作的桌面应用，它给出两种非常相似的派活方式，都放在侧边栏的 Agents 下面，挨在一起，点开还是同一个界面，区别只在团队规模。

单代理：一个名字，一个目的

Agent 在侧边栏显示为 Single agent，它只有一个名字和一个目的。你给它指令，它拿到自己的 ID，比如 AG-0001L，每次执行都按这个 ID 记录，方便日后追溯。

Agent team 则是在一组专业成员之上放一个领导者。领导者规划工作，把每一步派给某个成员，再由一名审核者在你看到结果之前逐项检查。如果你待过带项目经理的群聊，Agent team 的观感会很熟悉，差别在于每条消息、每次交接和每个判定都被保存下来，可以往回翻。

一个已结束的团队会话里，中间是与领导者的对话，标题写着“Leader · Orchestrate your team”。问题只问一次，组合后的答案也回到这里，例子里是一张表格，每行带一个来源，另有一行“Where sources disagree”和一行“Not covered”。

顶部中间的会话标签包括 Chat、Team mail、Email、Handoffs、Sub-agents、Proposals 和 Files。Handoffs 显示谁把工作交给了谁；Proposals 收集代理建议的文件或设置改动，建议在被接受之前不会生效。

右侧的 Agent session 面板为每个成员留一张卡，写着领导者要求它做什么、它调用了哪些工具（web_fetch、web_search）以及结果。每个结果下面能看到审核者的判定，例如“Approved”。上方有执行选择器“Run 1 · 07:40 AM”和 Cards / Graph 切换。

Team roster 标签是这次会话里能动手的成员名单。团队是一份成员花名册，不是一条工作流，工作的顺序来自领导者的计划。左侧的会话栏列出每个会话及其 ID，inspector 里有 Goal、Trigger 和 Hooks 三个标签，分别对应目标、触发这次执行的原因，以及围绕工作的各项控制。

三种典型用法

Priya 打开 Agent team，点 New session。在 New team session 窗口里保持选中“Start from a team”，从 Team 列表里挑 Deep Research Team。窗口随即载入它的五名成员：deep-research-agent、research-analyst、data-researcher、search-specialist、academic-researcher。“Who leads”下面显示 Orchestrator，说明它“plans the work up front, then delegates the steps to the agents below”。她也可以对任意成员点“make leader”换人指挥。

点 Create，在领导者的聊天里写下问题并发送。领导者把它拆成五块：找实验、找研究、找数字、找反面证据，最后合成一个答案。三名成员同时开工，Data Researcher 要等 Search Specialist 给出清单之后才去抽数据。当 Data Researcher 报出一个 40% 的数字时，审核者标记为“Sent back”，理由是缺来源、缺日期、缺指标。这一步被重跑，找到来源后才获批。

最终她拿到的是一个答案，每个数字都由找出它的代理之外的人核对过，还附一行诚实的“Not covered”，可以直接粘进给主管的备忘。

独立开发者 Tom 每周要把会议记录转成待办好几次，每次都要先往聊天里粘同一段规则。这份工作不需要团队，需要的是一个记得住规则的代理。他打开 Single agent，点 New session，停在 Create 标签，在“New agent”框里写一行需求，点 Start。打开的聊天本身就是一个配置代理，问几个问题后给出名字、@handle 和完整指令。输入框上方出现一张卡片，带名字、handle、Show instructions 链接和 Create agent 按钮。他打开指令，确认自己最在意的那条规则在：绝不猜负责人或截止日期。然后点 Create agent，同一个聊天就变成了那个代理。粘进会议记录时，缺失的负责人和日期被标为缺失，从不编造。会话在侧边栏保留它的 Agent ID，下次直接选这个代理就行。

Dari 负责一个小产品团队的发布。她的团队会话有一个领导者和 Release Drafter、Change Auditor、Docs Reviewer、QA Summarizer、Approval Prep 几名成员，各管发布包的一部分。执行前她打开 Goal 标签点 Set a goal，面板说明目标会被拆成若干成功标准，初始都是失败状态，随着代理逐项满足而变绿，会话持续到全部通过或触达轮次上限。她写了三条标准，最后一条是审批包必须完整。成员干活时，她看 Handoffs 追从领导者到每个成员再回来的链条，也看 Proposals 里成员建议的配置改动，那里没有任何一项会不经她手就生效。她随时可以在领导者的聊天里回复来引导它，面板头部的 Pause 能在她审阅时停下执行。最后她拿到一个发布包，以及一份谁写了、谁核了、谁批了每一部分的记录。

单代理还是团队

判断标准很直接：工作是一个规则固定的明确任务，比如重排笔记格式或按同一语气写回复，用单代理；工作包含需要不同工具的部分，或者你希望在你看到之前有一名独立审核者把关，用团队。

会话启动后团队不能换。New team session 窗口写明团队“is fixed for this session's life”。在按下 Create 之前，你仍可以在窗口内增删代理、指定谁指挥；要换一组人，就开一个新会话。

New session 提供 Local 和 Isolated 两种执行方式，两者都在你自己的机器上、用你自己的密钥运行，不上云。聊天历史默认保存在本地。

代理可以建议修改自己的指令，这些建议出现在 Proposals 里。建议不等于已接受的配置；代理能否动自己的提示词，是另一项独立设置。

Agent 和 Agent team 是工作开始的地方，Sessions 是跟进的地方。那块看板把每个聊天、代理、团队和终端会话显示为一张卡，按 Running、Needs you、Paused、Idle、Done 和 Failed 排列，依据是会话实际在做什么。同一份团队工作要反复跑时，Loop 用一个触发器、若干限制和逐轮的达标记录把它包起来；Graphs 用于路径取决于中途情况的工作。与领导者的对话是一个 Maestro 聊天，所以团队的答案可以接着流进 Maestro 里的其他工作。会话的 Enable sync 链接把它接到项目的消息频道，人和代理可以在同一个地方对话。