四天工作周能否保住产出？AI单干与组队给出两种答案

周二早上7点40分，普里娅手上有一个问题，午饭前必须给总监一个答复：四天工作周真的能保住产出吗？她可以把问题粘进某个聊天机器人，得到一段语气笃定的文字。但那个负责找数据的模型，同时也在判断数据对不对，而它几乎从不跟自己唱反调。普里娅想要的是：一个人去找试验，一个人去挖数据，再来一个人把没有来源的东西统统打回去。

osFoundry 是一款桌面应用，让 AI 的活儿跑在自己的机器上。它把任务交给 AI 的方式有两种，入口挨得很近，都在侧边栏的 Agents 下面，点开还是同一块屏幕，差别只在团队的规模。

单兵与团队，差在哪

Agent（侧边栏里显示为 Single agent）是一个有名字的智能体，只干一件事：你给它指令，它拿到类似 AG-0001L 这样的专属 ID，每一次运行都被记录下来，方便你事后回看。

Agent team 则是一个由专家成员组成的团队，前面站着一个 leader。Leader 负责规划工作，把每一步派给某个成员，在结果送到你手上之前，还有一名 reviewer 逐项检查。如果你待过那种配了项目经理的群聊，Agent team 会显得很眼熟。区别在于，每条消息、每次交接、每个决定都被保存下来，你可以往回翻。

一块屏幕上的团队会话

中间是跟 Leader 的对话，顶部写着“Leader · Orchestrate your team”。你在这里把问题问一次，混合后的答案也在这里出现，以表格形式呈现，每一行都带来源，下面还有一行“来源分歧之处”和一行“未覆盖”。

上方是会话标签页：Chat、Team mail、Email、Handoffs、Sub-agents、Proposals 和 Files。Handoffs 显示谁把活儿交给了谁；Proposals 里是 agents 建议对文件或设置做的改动，任何建议在被接受之前都不会生效。

右侧是 agent 会话面板。每个成员一张卡片，写着 leader 让它做什么、它调用了哪些工具（web_fetch、web_search）、结果如何。每个结果下面显示 reviewer 的判定，比如“已批准”。顶部有运行选择器（“Run 1 · 07:40 AM”）和卡片/图谱切换。

Team roster 标签页列出本次会话中有权干活的成员。团队是一份名单，不是一条工作流，工作的顺序由 leader 的计划决定。左侧的会话栏里，每个会话都带着自己的 ID；inspector 里有 Goal、Trigger 和 Hooks 三个标签，分别对应终点线、谁发起了这次运行、以及工作周边的检查。

三种用法

一位研究者要求每个数据都有出处。普里娅打开 Agent team，按下 New session，在对话框里保留“从团队开始”，从列表里选了 Deep Research Team。对话框载入它的五名成员（deep-research-agent、research-analyst、data-researcher、search-specialist、academic-researcher）。“谁来领导”下面显示 Orchestrator，说明写着“先规划工作，再把步骤派给下面的 agents”。她也可以点任意成员身上的“设为 leader”。

她按下 Create，在 leader 的对话里输入问题并发送。Leader 把它拆成五块：找试验、找研究、找数据、找反面证据，最后给一个答复。Data Researcher 要先等 Search Specialist 的清单，才去提取数据。当 Data Researcher 报出 40% 这个数字时，reviewer 把它标为“已退回”，因为它既没有来源，也没有日期，更没有测量口径。这一步重跑，找到来源，然后获批。

最后她拿到一个答复，其中每个数字都由找出它的那个 agent 之外的人核查过，还附上一行诚实的“未覆盖”，可以直接粘进给总监的笔记里。

一位独立开发者反复粘贴同样的指令。汤姆每周好几次要从会议记录里整理行动项，每次都要先把那段写满规则的文字粘进聊天框。这个活儿不需要团队，需要的只是一个记得住规则的 agent。

他打开 Single agent，按下 New session，停在 Create in chat 标签。在“New agent”框里用一行写下需求，按下 Start。打开的聊天是一个 setup agent，它问几个问题，然后建议一个名字、一个 @handle 和完整的指令。输入框上方出现一张卡片，带名字、handle、“显示指令”链接和“创建 agent”按钮。他打开指令，确认自己最看重的那条规则在里面：绝不猜测负责人或截止日期。然后按下创建，这段聊天就变成了那个 agent。当他粘贴笔记时，没有负责人和日期的条目会被标为缺失，永远不会被猜出来。会话把自己的 Agent ID 留在侧栏里，下次他只需选中这个 agent。

一位发布负责人想看清谁做了什么。达里负责一个小产品团队的发布。她的团队会话里有一个 leader，成员包括 Release Drafter、Change Auditor、Docs Reviewer、QA Summarizer 和 Approval Prep，各管发布包的一部分。

运行之前，她打开 Goal 标签，按下“设定目标”。面板说明目标会被拆成成功标准，一开始都是失败状态，随着 agents 逐项完成而变绿。会话会一直跑到全部通过或触及轮次上限。她写了三条标准，最后一条是审批包完成。成员干活时，她看 Handoffs，顺着从 leader 到每个成员再回来的链条；也看 Proposals，确认有没有成员建议改配置，那里任何东西不经她手都不会生效。她随时可以在 leader 的对话里回复来给方向，也可以按面板头部的 Pause 在审阅时暂停运行。

最后她拿到发布包，以及一份记录：每一部分由谁起草、审计和批准。谁要问笔记里某句话怎么来的，她都能指出来。

几个常被问到的问题

• 什么时候用单兵而不是团队？任务干净、规则明确时用 Single agent，比如重排笔记格式或按固定风格起草答复。任务的不同部分需要不同工具，或者你希望在你过目之前有另一个 reviewer 把关时，用团队。
• 会话开始后还能改团队吗？不能。新建团队会话的对话框里写明，团队“在此会话的生命周期内固定”。按下 Create 之前，你可以在对话框里增删 agents、选定 leader。要换名单就新开一个会话。
• 有东西跑在云上吗？新建会话表单里有 Local 和 Isolated 两种运行方式，说明写着两者都在你自己的机器上用你自己的密钥运行，什么都不上云。聊天记录默认留在本地。
• agents 能自己改指令吗？它们可以提改动建议，显示在 Proposals 里。一个 proposal 不等于已被接受的配置。agents 能不能碰自己的提示词，是另一项设置。

Agent 和 Agent team 是工作开始的地方，Sessions 是你查看它的地方。那块看板把每个聊天、agent、团队和终端会话显示成一张卡片，按 Running、Needs you、Paused、Idle、Done 和 Failed 分类，依据是会话实际在做什么。

同一个团队任务要反复跑时，Loop 会给一份名单套上触发器、限制和每一轮的记录，说明哪些标准通过了。Graphs 用于那种路径取决于中途发生什么的工作。带 leader 的那段对话是一个 Maestro 聊天，所以团队的答复可以接着进入你其他的 Maestro 工作。会话的“启用同步”链接把它接到项目的消息频道，人和 agents 可以在同一个地方说话。