Agent 开发认知和架构 & 推理规划和编排

做 Agent，先把一件事说清楚：模型一次只能做一次决策。它能连续查资料、调工具、改方案，是因为外面有一层程序在反复调用它，并把工具结果送回去。这层程序通常叫 Harness。

可以收成一句：

Agent = Model + Loop + Tools + Context Management

模型负责一次决策，Harness 负责让决策持续发生，并守住边界。

下面按这个公式，把落地方式、五种常用的规划模式、大脑系统的几种架构，以及多 Agent 如何协作，串成一条能直接拿去讲的线。例子尽量用同一件事：帮同事安排一次出差，需要查日程、机票、酒店和差旅政策，最后给出一份可执行行程。

1. 最小循环：决策是怎么接起来的

四项各管一块。

Model：读当前消息，决定下一步说什么，或者调用哪个工具。
Loop：模型说「我要调工具」时不把这句话当最终答案，而是执行工具，再请模型看结果。
Tools：日历、机票、政策库、数据库、内部 API。模型碰不到这些，只能提出调用。
Context Management：决定下一轮模型看见什么。原始任务要留着，过长的工具原文要压缩，近期的交互要完整。

把四项写成最小循环，就是：

python 复制代码

messages = [{"role": "user", "content": user_input}]

while True:
    response = llm(messages, tools=available_tools)
    messages.append(response)

    if response.stop_reason != "tool_use":
        return response.text

    for tool_call in response.tool_calls:
        result = execute(tool_call)
        messages.append({"role": "tool", "content": result})

用出差这件事走一遍。用户说「下周三去上海，待两天，订最省的往返」。模型第一轮不直接编机票，而是请求调用日程和航班工具。程序执行后，把「周三上午有会」「早班机票还剩两张」追加进 messages。模型看见这些结果，再决定订哪一班，或者继续查酒店。直到它不再请求工具，循环把那段文字返回给用户。

人看到的「它自己会办事」，就是这个循环在转。一次模型请求仍然只做一次决策。

Harness 让这个循环能放进真实业务，通常守三道边界。

生命周期。 同一查询重复出现时提前停下；另外设最大步数、最长时间和 Token 预算。出差助手若反复查同一班航班，应在第二次就停下来问人，而不是一直查到预算烧完。

工具边界。 只执行登记过的工具，调用前检查参数。模型若编出一个不存在的「订全部交通」，程序拒绝执行，并把可用工具列表送回去，让它改用机票和铁路工具。

上下文。 审计可以留下完整调用记录；送给模型的工作记忆则保留任务、关键事实和最近几轮。酒店查询返回的整页原文截断后，仍应留下「价格、是否含早、是否符合差旅标准」这几项，避免下一轮为了省 Token 把结论弄丢。

低代码、高代码、后面的规划模式和多 Agent，都是在这个循环上选择控制流放在哪里、工具和上下文交给谁管。

2. 两条落地路径

循环确定之后，要决定这套系统做在平台上，还是做在自己的代码里。

低代码：先把流程跑通

Dify、Coze 这一类平台把编排做成可视化节点。模型节点、知识库节点、条件分支和工具节点连在一起，就能在内网部署，并接上内部文档。客服和知识问答很适合走这条路：问题类型相对稳定，主要动作是检索资料、按话术回答、必要时转人工。

平台负责把「模型输出」接成「下一步节点」，验证一个想法的路径短。上线之后有两件事仍要单独安排：服务挂了如何拉起、扩容和降级怎么做；每一次回答依据了哪份文档、调了哪个接口，能不能追溯。这两件事是运行和审计，需要在平台之外补齐。

高代码：把边界做进调用链

LangChain 负责把模型、工具和链式调用组织起来，LangSmith 负责看见每一步的输入输出，模型可以换成部署在内网的私有化 LLM。框架提供的是骨架。业务边界要加在工具真正执行的前后，常见三层：

安全过滤。 用户输入和工具参数先过一遍规则，拦截敏感词、提示词注入和 SQL 注入，再决定是否发给模型和数据库。
工具认证。 调用内部系统时带上身份。OAuth 2.0 解决「这个 Agent 代表谁」，签名校验解决「这请求有没有被改过」。
审计中间件。 每个 Tool Call 的工具名、入参和返回值落下来。事后能回答「它为什么订了这张票、当时政策接口返回了什么」。

私有化模型解决的是数据留在哪。过滤、认证和审计解决的是工具能不能被这样调用。两件事要一起做。

怎么选

工具主要是检索和答复、希望几天内给业务一个可试用的版本，用低代码把客服或知识问答先搭起来，同时把高可用和审计列进上线清单。

工具会下单、改数据、花预算或进入权限系统，用高代码把过滤、认证和审计放在执行之前。出差订票、费用审批、生产环境操作，都属于这一类。

3. 规划和推理：九种模式里，先掌握五种

模型不会自动知道「先想清楚还是边做边想，哪些事可以一起做」。这是规划方式的选择。常见有九种：ReAct、Plan and Solve、REWOO、LLMCompiler、Basic Reflection、Reflexion、LATS、Self-Discover、STORM。

做系统时优先把下面五种用熟。它们覆盖了大多数任务：线性办理、计划会变、可以并行、要反复打磨、以及开放探索。

ReAct：思考，行动，再观察

每一轮都是三拍。先想当前知道什么、还缺什么；再调用一个工具；然后阅读工具结果，决定下一拍。

出差助手的线性版本就是这样：查日程，发现周三上午有会；查航班，锁定下午的班次；查酒店，按差旅标准筛选；最后写出行程。每一步都依赖上一步的真实结果，步骤顺序也清楚。

它适合线性、确定性的任务。规程明确、下一步由上一步的事实决定时，用这种循环最直接。工具结果会回到上下文里，所以单次结果尽量短，关键字段单独留住。

Plan and Solve：先规划，执行中再改计划

先列出完成任务的步骤，再按步骤执行。执行中若条件变了，就修改计划，而不是沿用已经失效的清单。

例如先计划成「订周三早班、住公司协议酒店、周四晚返回」。执行时发现早班取消、协议酒店满房，就重排成「周三下午出发、改住同标准的另一家、周四的会改到线上」。计划是动态的，任务仍是同一次出差。

它适合项目式、中途会变化的任务。原始目标和完成标准要单独记着，再规划改的是路径。行程可以改，「符合差旅政策、避开已有会议」这两条还在。

LLMCompiler：把互不依赖的步骤排成 DAG

能拆开、彼此不依赖的子任务，用有向无环图并行执行，再在汇合点合并结果。

日程、机票、酒店、天气、差旅标准可以同时查。五路结果到齐后，再生成一份行程。并行换的是等待时间。有先后关系的步骤仍要留在图的边上：没查到政策之前，不要先付款。

它适合可分解、子任务独立的任务。依赖要画对。汇合之后若证据不够，应回到规划再补查，而不是用残缺结果硬出一份行程。

Reflexion：生成，批判，再修订

第一版做完后，用明确标准检查，把问题写成可执行的修改意见，再出下一版。意见会留下来，下一轮先看上一轮错在哪里。

行程单第一版可能漏了「周四早上的会」。对照日程和政策检查后，记下「返回航班与已有会议冲突，且未写超标说明」。第二版改航班，并补上说明。评价标准来自日程冲突和制度条款，修订才有依据。

它适合质量驱动、结果需要验证的任务。标准要具体，例如测试是否通过、字段是否齐全、是否违反某条政策。有标准时，这个循环能把同一份产出越改越接近可用。

LATS：用树搜索探索开放问题

LATS 把树搜索、规划和反思放在一起。面对没有唯一路径的问题，同时展开多个做法，沿更有希望的分支继续，失败的分支留下原因，避免反复走同一条死路。

「怎样安排这次出差最合适」若还没有约束，就可能分出「当天往返」「住一晚」「改成远程」几支。每一支去查费用、时间和会议覆盖，再把明显不合适的剪掉，在剩下的分支上细化。

它适合开放式、探索性的复杂问题。展开分支会成倍消耗调用次数。步骤已经确定的办理流程，用 ReAct 或 Plan and Solve 即可。

其余四种，知道位置即可

REWOO：计划一次写完，工具调用用占位符串起来，执行完再统一作答。适合计划稳定、工具输出很长的资料汇总。
Basic Reflection：生成之后批判并改一版，发生在同一次任务里。比 Reflexion 少了「把失败原因带到下一次尝试」。
Self-Discover：解题前先选定一套推理结构，再按这套结构做。同类任务会反复出现时，用来固定思考方式。
STORM：从多个视角提问、检索、列大纲，再写成有资料依据的长文。它是写作流程，用来产出综述和说明，不用来直接订票或审批。

五种模式可以按任务形状来选：

任务形状	模式	出差例子里它在做什么
步骤清楚，每步都看上一步结果	ReAct	查完日程再查航班
项目会变，路径要改、目标还在	Plan and Solve	航班取消后重排行程
多件事互不依赖	LLMCompiler	机票、酒店、政策并行查
产出要对着标准改到可用	Reflexion	行程单对照会议和政策修订
路径很多，需要试探和剪枝	LATS	比较当天往返、住宿和改远程

产品里怎么用：WorkBuddy 和 Claude

腾讯 WorkBuddy 和 Claude Code 都没有单独实现全部九种模式。日常办事靠 ReAct，任务一大就切到 Plan and Solve，独立的调查可以并行。Reflexion 和 LATS 不是它们的主路径。

WorkBuddy 是办公工作台，文档里把工作方式分成三档。

默认 Agent 模式是 ReAct。 目标清楚时直接执行：模型请求工具，程序校验权限后执行，结果回到上下文，再决定下一步。整理文件、写文档、处理表格，都在这个循环里完成。官方对一次完整任务的描述也是这条循环：读记忆和技能、查资料、调用工具、补缺口、交付结果。
计划模式是 Plan and Solve。 多步骤、需求还模糊、或结果成本高时先出方案。模型补齐时间、预算、范围等前提，给出可审阅的计划；人确认后才执行，确认前可以删减、调序或重来。执行阶段仍按 ReAct 调工具，依据是已经确认的方案。
并行发生在子任务上，不是把整次任务编译成一张 DAG。 工作台可以同时开多个任务。单次复杂调研里，主 Agent 会把互不依赖的材料分给 Sub-agent 分头查，再汇总。这一段用到了 LLMCompiler 的「独立子任务同时做」，主循环还是 ReAct 加上必要时的再规划。
做完会核对结果，例如文件是否整理到位。这是验收，还没有做成 Reflexion 那种「把失败原因记下来、整单重做」，也没有 LATS 那种多分支搜索。

Claude Code 的主循环同样是 ReAct。Claude 读当前上下文，决定回复文字或调用工具；Harness 执行工具，把结果送回；直到这一轮不再调用工具。一轮里如果几件工具互不依赖，可以一次发出多个调用，例如同时读几个文件。这是并行取结果，不是事先编好整张 DAG 再按图调度。

复杂改动会进入 Plan 模式，对应 Plan and Solve，而且比直接开写多了两步约束：

先只用只读工具看代码、依赖和现有写法。
把要改哪些文件、按什么顺序改、步骤之间有什么依赖，写成计划。
对照用户要求自检计划是否覆盖完整、顺序是否可行。
把计划交给人确认。确认之后才进入会改代码的执行循环。

探索性的阅读可以交给 Plan 子代理 或 Explore 子代理 ，在单独的上下文里查，只把摘要交回主会话。这是编排器-工作者：主会话当编排器，子代理当工作者。另有一类 Verification 子代理 跑测试和检查，用来确认改动是否站得住，接近「对着标准看一遍」。它服务的是交付前的验收，不是把整个任务做成 Reflexion 的多轮重写，也不是 LATS 的树搜索。Claude Code 每一轮会沿当前选择继续，不把多条改法同时展开再剪枝。

两边可以对照着记：

	默认怎么干活	任务变大时	并行	不作为主路径
WorkBuddy	ReAct，直接执行	Plan 模式：先出方案，确认后再做	多任务，以及 Sub-agent 分头调研	Reflexion、LATS
Claude Code	ReAct，工具结果驱动下一步	Plan 模式：只读勘察、写计划、人确认后改代码	一轮内多个互不依赖的工具；子代理分头查	Reflexion、LATS

所以看到这两个产品「会自己规划」，指的是 ReAct 循环之上加了一层 Plan and Solve。规划方式仍按任务切换，没有换成树搜索。

4. 大脑系统：四步演进，每一步对应哪些架构

单个循环之外，还要决定大脑怎么搭。演进是四步，每一步用到的架构模式不同。

演进	谁决定下一步	对应的架构模式
1. 给模型补上检索、工具和记忆	还没有多步路线	增强型 LLM、工具调用和记忆
2. 把常见控制流做成固定拓扑	路线事先画好，模型只填每一步的内容	提示链、Agent 路由器、并行 Agent、编排器-工作者、评估器-优化器
3. 开放循环	模型根据工具结果临时决定下一步	第 1 节的 Loop。DeepSeek V3.2 加强的是这一步里的思考
4. 多个大脑互联	一个 Agent 把子任务交给另一个 Agent	A2A

第一步：增强型 LLM，加上工具调用和记忆

模型本身回答不了「公司差旅标准是什么」。加上检索、工具和记忆之后，才能查到内部规定、订到实时机票，并记住这次已经确认的偏好。记忆里放原始目标、已核对事实和待办。已经合并进事实的长原文不必再整段保存。

这一步只有一个模型在工作，还没有「先走 A 再走 B」的路线。

第二步：固定拓扑

路线反复出现、步骤和分支画得出来时，把控制流画成固定的图。模型不再决定下一步交给谁，只负责把当前这一步做完。固定拓扑就是下面五种，可以单独用，也可以串起来。

提示链。 已知步骤串成一条线。例如「抽取出发地和日期 → 检索政策 → 按模板写出行程说明」。每一步的输出是下一步的输入。

Agent 路由器。 先判断请求属于哪一类，再进入对应流程。「查政策」进知识库，「改行程」进订票，「报销咨询」进财务说明。

并行 Agent。 互不依赖的部分同时做，到齐再合并。机票、酒店、天气一起查。对应第 3 节 LLMCompiler 里的并行，只是路线已经画在图上，不由模型临时编排。

编排器-工作者。 编排器拆任务、定接口，工作者各自完成一块再交回。编排器看行程是否覆盖全部会议，工作者分别负责票、酒店和地面交通。

评估器-优化器。 一个角色产出，另一个角色按清单打回。评估器对照差旅制度逐条看，优化器只改不合格的项。

五种可以组合。路由器先分流，「改行程」进入一条提示链；链中间用并行 Agent 同时查机票和酒店；最后用评估器对照差旅标准。图仍然是事先画好的。

第三步：开放循环

下一步取决于上一步的真实结果、事先画不出完整路线时，用第 1 节的 while True。模型自己决定调用哪个工具。Harness 管住步数、白名单和上下文。WorkBuddy 的默认 Agent 模式、Claude Code 的主循环，都在这一步。

DeepSeek V3.2 加强的是这一步里的单次决策。它把思考和工具调用放进同一次模型行为：看到周三上午有会，再决定查下午的航班。外层循环不变。步数、白名单、审计和上下文仍然由 Harness 负责。

第四步：用 A2A 把多个大脑连起来

多个 Agent 要互相发现、委托任务、交回结果时，用 A2A（Agent-to-Agent）。工具协议解决如何调用一个 API，A2A 解决如何把一件子任务交给另一个 Agent。

出差场景里，行程 Agent 把「订符合标准的酒店」委托给酒店 Agent，把「核对预算科目」委托给财务 Agent。委托带上目标和约束，交回订单号和价格这种可核对的结果。每个 Agent 自己的循环仍然有自己的工具清单和停止条件。

5. 协作：从一个人到一支分布式团队

一个上下文装得下的任务，单 Agent 最清楚。大型重构、十几处联动修改，主会话会把目标、搜索结果和半成品挤在一起，做到后半段已经看不全前半段。Claude Code 的做法是让主 Agent 当项目经理：理解需求、拆解任务、分配工作、跟踪进度、整合结果。具体执行交给它创建的子 Agent。

这是把已经在人类团队里验证过的项目管理放进代码。角色、交接、验收、进度可以延续、成员可以分布在不同地方，对应下面五级。每一级只补上一级还没有的那一种机制。

级别	角色	新补上的机制	再往上走的信号
1. 单 Agent	全栈工程师	一个上下文里做完	目标和工具原文挤在一起
2. 多 Agent	项目经理 + 专员	分工、委派、验收	专员之间要随时对齐，干等结果来不及
3. Agent Swarms	同办公室的同事	共享状态、邮箱、动态领任务	一次会话结束，进度就没了
4. 跨会话持久化	可以读档的项目	进度存在会话之外	协作者不在同一台机器上
5. 跨机器协作	分布式团队	身份、授权、审计	---

项目经理的五件事，从第 2 级才成套出现。

理解需求。 老板说「把系统从 Python 2 升级到 Python 3」，先确认范围，而不是直接改文件。
拆解任务。 列出要改的模块、要升级的依赖、要更新的测试。
分配工作。 前端、后端、测试各交一个子 Agent，并写清完成标准。
跟踪进度。 任务有状态，产出可以中途查看。
整合结果。 各块合并后，主 Agent 确认整体还能用。

1. 单 Agent：全栈工程师

一个上下文里完成调研、调用和成稿。主会话自己读文件、改代码、跑测试。出差只涉及日程、一班机票、一条政策时，也适合停在这里：工具少，约束一个人看得完。

所有事实和中间步骤都在同一段历史里。任务变大以后，搜索原文把原始目标冲淡，模型开始漏改文件，或者重复查已经查过的目录。

往上走的信号：一份任务要碰的模块，已经多到主会话记不住「谁改了什么、还剩什么」。

2. 多 Agent：明确分工

主 Agent 留下需求和验收，子 Agent 各拿一块，上下文切开。政策 Agent 只回答制度和是否超标，订票 Agent 凭这条结论下单，写作 Agent 只组装行程单。每个角色交出的内容要能被下一家验收。政策 Agent 给出条款和是否超标；订票 Agent 给出订单号和价格。两家各写一份行程，分工就没有成立。

Claude Code 里，分工的地基是任务系统。主 Agent 不直接「喊一嗓子」，而是创建一条带类型的任务。

任务类型	角色类比	做什么
`local_bash`	跑腿	在本地 Shell 里跑测试、编译、构建
`local_agent`	本地开发者	独立子 Agent，在本机完成一块复杂工作
`local_workflow`	流水线工人	执行事先写好的工作流脚本
`in_process_teammate`	同桌搭档	同一进程里紧密协作，第 3 级才用到
`remote_agent`	远程外包	通过远程 API 调用另一台机器上的 Claude Code，第 5 级才用到
`monitor_mcp`	哨兵	盯 MCP 服务的状态变化
`dream`	夜间值班	空闲时在后台做代码分析或预计算，给下一轮交互做准备

任务 ID 带类型前缀，例如本地命令以 b 开头、本地子 Agent 以 a 开头、同进程队友以 t 开头，后面再加随机字符。看前缀就知道这是哪一种工作。

派发本地子 Agent 时，主 Agent 交出四样东西：这段工作的职责、具体指令、使用的模型、最大轮数。最大轮数是第 1 节的生命周期，避免子 Agent 自己停不下来。模型可以选更小的一档，用来控制这块工作的成本。

每条任务走同一套状态机，终态一旦写下就不再改：

text 复制代码

创建 → pending
开始 → running
需要权限 → waiting_permission
            ├─ 批准 → 回到 running
            └─ 拒绝 → 换一种做法继续，或结束
结束 → completed / failed / killed

生命周期分成五段：创建时生成 ID、状态记为 pending、注册到全局状态；执行时切到 running，并持续写下输出；终结时记成 completed、failed 或 killed，通知父级；查询在任何时候都能读状态和输出；清理时从全局状态移除。输出落在文件里，主 Agent 按偏移量读新增的一段，像项目经理翻开发日志，不用把子任务的全部过程拷进自己的上下文。

往上走的信号：子任务之间要频繁对齐。前端在等后端的接口形状，派出去干等一份最终结果，中间改动对不上。

3. Agent Swarms：紧密配合

第 2 级是把活派出去，等一块块结果回来。第 3 级是几个人坐在同一间办公室，边做边说话。高度耦合的改动适合这种配合，比如同时做 CSS 迁移和组件改造：组件的类名一变，样式任务就要立刻知道。

两种派法要分开。

	`local_agent`	`in_process_teammate`
类比	派出去的独立开发者	坐在旁边的同事
运行位置	进程外	同一进程
结果怎么交	通过输出文件	共享内存和状态，并用邮箱说话
适合	边界清楚、做完再交	频繁协调、谁做完谁领下一件

Swarm 靠三样东西转起来。

共享状态。 任务板上能看见哪些做完了、哪些在做、哪些可以领。机票查询结束后，酒店任务立刻被领走。文件状态还可以共享缓存，避免两个人重复读同一批文件。没有这块板，多个循环会重复查同一班航班，或者互相覆盖同一份行程。

邮箱 Mailbox。 主 Agent（Lead）和队友之间不靠把对方的上下文拼进来，而靠消息。每个 Agent 有自己的收件箱，消息写成 JSON，用文件锁避免两个人同时写。进程崩了，已经写入的消息还在。接收方在下一轮工具调用，或大约每秒的轮询里读自己的收件箱，发送方不用停下来等。

消息有两种去向：私信给某一个队友，或广播给全队。常见载荷就四类。

载荷	用来做什么	例子
任务通知	分配、同步状态和依赖	「修复登录页 CSS 溢出」，状态从 assigned 到 done，并写明依赖哪条任务
权限请求	队友自己不做安全决定	要执行一条高风险命令，写明工具、原因、风险等级
点对点询问	向指定队友要一个事实	「你看 `utils.ts` 时，`handleAuth` 的实现在哪一段？」
关闭信号	结束这块工作	任务完成，退出码 0

创建 Swarm 用的工具也按这三样分开：AgentTool 创建进程外的 local_agent，TeamCreateTool 创建同进程队友，SendMessageTool 往邮箱里写信，TaskOutputTool 让父 Agent 读子任务产出。主 Agent 在内存里排好执行关系，再把职责和指令放进工具参数。

权限冒泡。 并行之后要防止某个队友自己扩大权限。子 Agent 继承父级的允许和拒绝清单。它需要清单外的能力时，自己不批准，把请求冒泡到父级，最终由用户确认，结果再传回去。同一条被拒绝的操作会记下来，避免反复弹同一句询问。这和公司里新同学申请系统权限一样：向经理申请，经理同意或拒绝。

进度可以推到看板上。Bridge 用 SSE 把每个 Agent 的状态送到 IDE，效果类似项目管理里的实时看板。主 Agent 和每个子 Agent 的 Token 分开记，才能看出钱花在协调上还是花在执行上。dream 任务利用空闲时间做后台分析，像开发者下班前把明天要看的结构先理一遍，下一轮交互直接用这份结果。

往上走的信号：活做不完一次会话。今天确认了升级范围，明天依赖仓库才更新，进程一停，任务板和对话一起没了。

4. 跨会话持久化：时间穿越

一次 while True 结束，内存里的消息就没了。出差往往跨几天：今天确认预算，明天航班取消要改签。代码升级也一样，中断后要从上次的任务清单继续，而不是重新理解需求。

Claude Code 用两种方式接着做。

	`--resume` 读档	`--continue` 续集
恢复程度	把现场找回来，适合断点续跑	带上历史摘要，开启下一轮对话
适合	同一件事没做完	事情告一段落，下一步换一个焦点

--resume 恢复七类状态：

消息历史。 之前的对话。
文件历史快照。 哪些文件改过，改之前是什么样。
归属状态。 哪些变更是 Agent 做的，便于提交时记清作者。
上下文折叠提交。 已经压缩进版本历史的那些提交信息。
TODO 列表。 上次规划的任务清单。
Agent 设置。 子 Agent 的配置和状态。
Worktree 状态。 Git 工作树停在哪里。

持久化的是可继续的进度：原始目标、已核对事实、未完成事项、任务状态。已经写进事实的检索原文不必原样再带一遍。任务输出本来就在文件里，所以查询和恢复用的是同一份日志。

往上走的信号：执行的人不在同一台机器上。订票、政策、审批分属不同系统；或者一个子 Agent 要跑在另一台有专门环境的机器上。

5. 跨机器协作：分布式团队

remote_agent 通过远程 API 调用另一个 Claude Code 实例，角色像远程外包。它跑在另一台机器上，父级仍用第 2 级的状态机跟踪：创建、执行、终结、查询、清理。

跨机器之后，第 2 节的三层变成协作的一部分。

身份和认证。 OAuth 2.0 回答「这个 Agent 代表谁」，签名回答「委托和参数有没有被改过」。
权限。 远程队友继承的允许清单更窄。高风险操作继续冒泡到主 Agent，再冒泡到人。
审计。 每一次远程 Tool Call 留下工具名、入参和返回值，并能对上同一次委托：谁让订的、用的哪个工具、返回的价格是多少。

一台机器上的演示可以把白名单写在进程里。人和 Agent 分布开之后，每台机器都要能验证对方。Mailbox 那种本机 JSON 文件，到这一级要换成双方都认可的消息通道，消息格式仍然可以沿用任务通知、权限请求、点对点询问和关闭信号。

怎么升级

按已经出现的限制往上加一级。上下文还装得下，保持单 Agent。主会话记不住分工，再上项目经理和任务状态机。专员之间要边做边对齐，再上 Swarm 的共享状态和邮箱。任务活过一次会话，再把七类现场存下来。信任边界跨了机器，再补认证和审计。

出差助手若只是查完日程订一张票，停在第 1 级。政策、订票、行程单要分开验收，上到第 2 级。这三块要按对方的最新结果马上改，上到第 3 级。审批要隔天继续，上到第 4 级。订票系统、政策库和审批系统不在同一台机器上，才上到第 5 级。