架构：把不确定的判断放在可控制的系统里

用户说“卡没收到”，产品应帮助他查明状态并继续处理。架构的第一件事是决定：什么事实由后台提供，哪些判断允许模型作出，什么动作需要用户确认，发生故障时谁继续工作。先把这笔任务走通，再选择编排框架。

从任务分工选择架构

同一个客服场景至少有三种合理方案。只需查配送状态时，表单加查询接口就足够；状态解释和追问有变化时，可以用固定流程加模型处理语言；调查路径随客户回答改变时，可以允许模型选择领域工具。三者可以共存，例如模型处理对话，规则检查补卡资格，普通软件执行事务。

Nubank公开研究支持后一种分工：例程提供调查路径，模型选择下一步，领域工具获取事实或执行动作；固定跨系统依赖封装在代码里。这里采用这个边界原则，不推定其私有服务拆分，也不把收益数字当作这种架构的通用保证。Nubank论文§4.2–4.3

另一个边界是成果的形态。IBM DataStage Assistant将流程生成、表达式生成和文档问答分为能力路径，成果回到可编辑画布。流程草案可以由模型生成，运行数据作业仍是另一项业务动作。对合同草拟、商品资料建档、报表设计，这种“生成可检查产物”的结构往往比自主执行更合适。

画出权力与状态，而不是只画组件

以下为原创教学架构：客户端发任务；应用服务维护状态；上下文构建器提供必要信息；模型提出下一步；执行层检查授权和参数；后台返回业务结果；应用将结果呈现或移交人工。模型不能凭输出文本修改已确认状态。

用户请求 → 任务服务 → 上下文构建 → 模型候选
                ↑                    ↓
           结果与状态 ← 执行层授权/校验 ← 下一步动作
                ↓
       用户可见结果 / 带上下文交接

应独立存储一个最小任务对象，不能仅靠聊天记录恢复进度：

{
  "task_id": "demo-42",
  "kind": "card_delivery",
  "state": "investigating",
  "subject_ref": "customer-from-session",
  "facts": {"delivery_status": "delivered", "observed_at": "2026-10-07T09:00:00Z"},
  "pending_action": null,
  "accepted_result": null,
  "config_version": "delivery-demo-1"
}

subject_ref来自认证会话；模型提供的客户编号不是身份凭据。facts标明事实时点；pending_action保存待确认提案；accepted_result仅在后台取得可靠结果后写入。业务对象与会话分离，使用户断线、工具超时、人工接手后仍能判断发生了什么。

用失败决定服务边界

假设模型建议补卡，后台已经创建请求，但返回途中断线。若应用直接重试“创建”，可能重复；若回复失败，也可能让客户再次操作。需要将命令接受、业务执行和结果查询分开：写动作使用稳定请求ID，超时进入结果核对，无法核对时交人工，不再盲目发第二个写动作。

不一定需要一开始拆成微服务。一个应用也能明确区分身份、任务状态、模型适配、工具执行和审计模块。只有不同吞吐、故障隔离、团队职责或发布周期要求独立运行时，再拆部署单元。反过来，把每个模型角色变成独立服务，会增加网络、版本和调试成本，未必提高业务能力。

数据边界同样重要。Finch披露了受治理的单表集市、字段与值的别名及执行前权限检查。迁移设计还应按任务配置只读凭据、允许查询范围与超时；这些是本手册的控制建议，原文未披露其具体实现。“不要写数据”的Prompt不能替代数据库凭据和查询检查。架构评审应拿一条合法请求和一条越权请求，沿每个边界检查谁拒绝、留下什么记录、用户看到什么。

自然语言入口不一定需要开放式执行

文档编辑任务有另一种边界：用户说“把所有标题加粗”，系统先生成受限中间表示，再由普通程序完成选择、校验与格式修改。Microsoft的Semantic Interpreter将自然语言映射到Office领域语言ODSL，转译到应用API；§5的Analysis-Retrieval先确定相关实体和是否需要当前文档，再组织语法与样例。模型不需要自由编写任意脚本，应用也不必把所有内部API暴露给它。原论文v1，§4–6

下面是原创受限操作，不是ODSL原语法：

{"document_revision":"rev-18","select":{"kind":"title"},"action":{"set_bold":true}}

执行器只接受白名单字段，检查文档版本和匹配对象，向用户提供预览与撤销；找不到标题时返回空结果，文档已变更时要求刷新。评测比较实际修改集合和允许结果，而不是要求模型输出与标准JSON逐字一致。受限表示适合对象与动作可枚举的编辑、报表或流程草稿；开放调查则未必能先写完整语法。新增转换器只有在可测试、可维护时才值得，不能把“用了DSL”视为可靠性证明。

协作任务也不应从“增加Agent数量”开始。MetaGPT的可迁移点是PRD、设计、代码等中间产物合同，共享消息池及订阅，以及代码执行后的错误反馈；其软件开发基准不是企业组织提效证明。MetaGPT v5，§3.1–3.3 若一条确定性流水线已经能传递这些产物，就先用流水线。只有并行专业判断和独立验证确有收益时才增加角色，同时检查错误产物怎样阻止下游继续、返工是否有上限。表示与训练的进一步取舍见离线学习与表示设计。

怎样判断当前方案够用

在增加编排复杂度之前，以相同任务集比较普通界面、固定流程和有界工具方案，记录正确结果、人工时间、交互往返、延迟、成本与恢复失败。至少演练事实过期、授权拒绝、超时后结果未知、用户取消和转人工。较复杂方案必须证明它解决了较简单方案的具体缺口。

架构产物应让一个未参加讨论的工程师回答：模型在哪些位置可以决定，谁控制事实与权限，动作完成以什么为准，异常如何继续。用方案记录保存当前取舍，随后进入模型与上下文和工具集成。

工作蓝图如何变成一次完整请求，直接看下一章的SUP-08/SKU-017展开包；候选校验后再进入第12章的保存合同。

参考资料

• Nubank v2，§4.2–4.3：上下文与复合工具。
• DataStage部署论文：可编辑ETL能力路径，区别于工业维护。
• Semantic Interpreter v1，§4–6：受限表示；MetaGPT v5，§3.1–3.3：中间产物与反馈协议。
• Uber Finch：受限分析；图与任务对象为合成教学设计。

继续使用

上一章：组织数据与知识 · 下一章：模型与上下文 · 五篇阅读目录。相关工具：候选架构与责任分工。

对照案例：Amazon异常规则、ABB控制逻辑生成、IBM维护。