从问答到任务交付：大模型智能体的工程化实践

一、评价大模型升级，应先改变评价对象

讨论新一代大模型，容易把注意力集中在回答是否流畅、推理是否深入、生成代码是否完整。这些指标依然重要，但当应用开始处理跨文档、跨系统、多步骤的工作时，单轮回答质量已经不足以代表实际价值。

真正值得关注的问题是：系统能否理解一个完整目标，将其拆解为可执行步骤，在授权范围内使用工具，并交付满足要求的成果。

例如，“总结这份材料”主要考验文本理解与归纳；而“整理多个来源的资料，核对关键结论，形成分析报告和数据表，并标注尚未确认的信息”，则同时涉及信息检索、来源判断、数据转换、文件生成和质量检查。

后者不是一次更长的文本生成，而是一条需要管理状态、处理异常、验证结果的执行链。

因此，评价这类系统时，需要区分三个层次：

• 模型层：理解、推理、生成和选择工具的能力。
• 编排层：组织步骤、管理依赖、保存状态和处理失败的能力。
• 业务层：定义交付标准、控制权限、衡量成本并落实责任的能力。

这三个层次共同决定交付效果。不能将整套应用的表现全部归因于模型，也不能把模型具备某项能力，直接理解为所有使用场景都已具备相应功能。

二、从目标描述开始，而不是从模糊指令开始

复杂任务失败，往往不是因为系统完全无法执行，而是因为用户与系统对“完成”的理解不同。

“帮我研究这个问题”没有明确范围，也没有验收标准。系统即使生成一篇长文，也可能遗漏时间范围、使用过期资料，或者给出无法追溯的结论。

更稳妥的方法，是将需求整理成一份“任务契约”。

1. 明确输入边界

输入应说明允许使用的材料、资料的时间范围、可访问的数据源，以及不得处理的信息类型。

如果任务涉及内部文件，还应明确哪些目录可读、哪些字段属于敏感信息、哪些内容不能进入最终报告。不能把“系统能够访问”视为“系统可以任意使用”。

2. 明确交付物

交付要求应尽量具体，例如：

• 一份包含背景、分析、风险与建议的报告；
• 一份字段定义明确的数据表；
• 一份来源清单；
• 一份未解决问题及其原因说明。

这些要求可以减少系统只输出文字说明、却没有形成实际成果的情况。

3. 明确完成条件

“内容专业”很难直接验收，而以下条件更容易检查：

• 关键事实附有可追溯来源；
• 数值结论注明单位、时间范围和统计口径；
• 文件可以正常打开；
• 必填字段无遗漏；
• 无法核实的结论单独标注；
• 对外发送、覆盖文件等操作经过授权。

任务契约不必写得冗长，但应让用户、执行系统和验收程序对目标形成一致理解。

三、长链路任务的核心，是规划、执行与验证闭环

多步骤任务并不是把一条长指令切成几段，然后依次调用模型。可靠执行需要在每个关键阶段确认：当前结果是否仍然满足原始目标。

一种通用流程是：

需求解析 → 任务规划 → 工具执行 → 中间验证 → 必要时修正规划 → 交付验收

1. 规划需要表达依赖关系

以资料分析为例，数据清洗必须先于统计，统计结果应先于图表生成，报告中的结论又需要建立在经过核对的数据之上。

如果忽略这些依赖，系统可能先写结论，再寻找材料补充论据。这会提高确认偏差和事实错误的风险。

工程上可以将任务组织成依赖图：没有前置依赖的步骤可以并行执行，需要共享结果的步骤则按顺序推进。并行不是越多越好，还应受到资源配额、数据源限流和成本预算约束。

2. 验证需要独立标准

让生成内容的模型再次判断“是否正确”，可以提供辅助检查，但不能代替独立验证。

不同结果应采用不同的检查方法：

• 数值计算由确定性程序复算；
• 表格检查字段、类型、重复记录与单位；
• 文档检查章节、引用和必要说明是否齐全；
• 文件检查格式和可读性；
• 外部操作检查实际返回状态，而不是只读取自然语言描述。

对于不能自动判定的内容，应保留人工复核入口。

3. 停止条件必须提前设计

执行链不应无限循环。系统需要设置最大执行步数、总耗时、累计预算和重复失败阈值。

达到阈值后，应交付当前成果、失败原因和待确认事项，而不是继续尝试直到资源耗尽。明确说明“哪些已经完成、哪些尚未完成”，通常比生成一个表面完整的答案更有价值。

四、工具调用：从“建议怎么做”到“真正完成操作”

工具让模型能够获取信息、运行计算、读写文件和操作业务系统，但也会将生成错误转化为实际影响。因此，工具调用必须经过受控执行层。

1. 采用结构化调用与参数校验

模型提出的操作请求，应包含明确的工具标识、参数和预期结果。执行层负责检查：

• 工具是否在允许列表内；
• 参数类型和取值范围是否合法；
• 当前身份是否具有权限；
• 目标资源是否属于授权范围；
• 操作是否需要人工确认。

执行结果也应采用统一结构，包含成功状态、错误类别、产物位置和必要的审计信息。

模型生成的操作意图只是候选请求，不应天然具有执行权限。

2. 优先使用受控接口

对于长期运行、重复频繁的业务流程，结构化接口通常比模拟页面点击更容易验证和审计。页面结构、按钮位置或交互流程变化，都可能使界面自动化失效。

当确实需要通过界面操作时，应增加关键页面状态检查，并对提交、发送、删除等动作设置确认机制。不能因为前一步点击成功，就推断后续业务操作已经完成。

3. 区分低风险与高风险动作

读取公开资料、生成草稿，通常比修改业务记录、发送外部消息和删除文件风险更低。

可以按风险采用不同控制方式：

• 低风险动作在授权范围内自动执行；
• 中风险动作先展示预览或变更清单；
• 高风险动作要求明确确认，并保留操作记录。

控制重点不是“让用户确认每一步”，而是让关键风险不被隐藏在冗长执行链中。

五、状态管理决定系统能否继续、纠偏和恢复

长任务不能只依赖对话历史保存进度。对话适合沟通，却不是可靠的任务状态数据库。

至少应分别保存以下信息：

• 目标状态：当前有效的需求、约束和验收条件；
• 执行状态：各步骤的进度、依赖、重试次数和错误；
• 产物状态：文件版本、数据快照、来源记录和校验结果。

这种分离使系统在进程中断、工具超时或用户修改需求后，能够判断哪些工作仍然有效。

1. 中途修改需要识别影响范围

假设用户在报告生成过程中，将分析范围从“全部业务”改为“某一业务线”。系统不能仅修改标题，而应重新判断数据筛选、统计表、图表和结论是否需要更新。

合理的做法是记录需求版本，并将依赖旧条件生成的产物标记为待更新。对不受影响的资料收集结果，则可以继续复用。

2. 异步执行需要任务标识与检查点

耗时操作适合异步执行，但这需要配套的任务标识、状态查询、超时处理、取消机制和进度通知。

检查点应保存在可恢复的位置。服务重启后，系统能够从最近的有效状态继续，而不是让模型根据残缺上下文猜测进度。

3. 重试前必须确认副作用

查询失败通常可以重试，但创建记录、发送通知等操作不能直接重复提交。

对于有副作用的操作，应使用幂等标识，或先查询前次执行结果。否则，一次网络超时可能最终产生两条业务记录，甚至造成重复发送。

六、安全边界：外部内容不是执行指令

智能体会读取网页、文档、表格及其他外部材料，其中可能包含诱导其忽略原任务、泄露信息或调用额外工具的内容。

这类风险的关键在于：系统把“需要分析的数据”错误地当成了“必须遵守的指令”。

因此，应用应明确区分指令来源与数据来源。外部材料可以用于提取事实、形成摘要，但不能据此扩大访问权限或改变安全规则。

配套措施包括：

1. 对敏感字段进行访问控制和必要脱敏；
2. 为不同工具分配最小权限；
3. 限制文件读写路径与网络访问范围；
4. 在隔离环境中运行不可信代码；
5. 对导出数据和对外发送设置审查；
6. 记录工具调用、权限判断与关键变更。

这些措施只能降低风险，不能替代业务责任划分。尤其在高影响场景中，应明确谁有权批准操作、谁负责复核、出现异常时如何回退。

七、用完整案例建立交付闭环

以“整理内部业务资料并输出分析报告”为例，可以将实施流程划分为六个阶段。

阶段一：登记资料

记录文件来源、更新时间、访问权限和可用状态。对于无法读取或缺少关键字段的文件，应尽早列出，而不是到最终报告阶段才暴露问题。

阶段二：统一口径

检查日期、单位、统计周期和指标定义。不同材料中的同名指标不一定可以直接合并，必须先确认口径一致。

阶段三：执行分析

由确定性程序完成筛选、汇总和计算，模型辅助解释变化、整理可能原因。推测性解释应与已证实事实分开呈现。

阶段四：形成成果

先生成经过验证的表格和图表，再撰写报告。这样可以降低正文与底层数据不一致的概率。

阶段五：自动验收

检查数值能否复算、结论能否定位到依据、文件能否打开、必备章节是否齐全，以及是否存在未经授权的信息。

阶段六：人工确认与交付

人工重点审阅关键判断、敏感信息和行动建议。交付时同时提供限制说明与待确认问题，而不是仅给出一个看似确定的最终结论。

这个案例说明，可靠系统需要让模型推理、确定性程序和人工判断各自承担适合的职责。

八、评测应衡量端到端结果，而非展示效果

上线前应建立接近真实工作的评测集，既包含正常任务，也包含资料缺失、来源冲突、工具超时、用户中途修改要求等异常场景。

重点指标包括：

• 交付成功率：是否达到预设验收条件；
• 事实可追溯性：关键结论是否有有效依据；
• 执行稳定性：重复运行是否容易出现明显偏差；
• 恢复能力：失败后能否继续并避免重复副作用；
• 人工介入成本：用户需要补充、纠正和返工多少；
• 总体成本：推理、工具、存储与复核的综合投入；
• 完成时延：用户从提交任务到收到可用成果的时间。

单步准确率高，并不代表整条链路可靠。在简化的独立同分布假设下，若每个环节的成功概率为 p，连续 n 个环节全部成功的概率为 p 的 n 次方。实际系统中的失败往往还存在关联，因此更需要通过端到端测试确认，而不能简单叠加单项成绩。

九、采用渐进上线，而不是一次性交出全部权限

智能体应用适合按风险逐步部署。

首先运行只读流程，验证检索、分析和报告质量；随后允许生成草稿与待审批变更，但不直接影响正式数据；最后，再将范围明确、可回退且经过充分验证的低风险操作纳入自动执行。

扩大自动化范围之前，应确认异常监控、预算限制、人工接管和回退流程已经可用。不同用户、入口或权限配置下，实际可用能力也可能不同，因此应以部署环境中的真实验证结果为准。

结语：升级的价值，在于把结果做得可用、可信、可控

从问答走向任务交付，是大模型应用的重要方向，但“能够规划和调用工具”只是起点。

真正可靠的系统，需要把目标写清楚，把权限限制住，把执行状态保存下来，把每项重要成果验证到位，并为失败和人工接管留下通道。

对开发者而言，最值得投入的不是让演示流程显得更自主，而是让真实流程中的每一步都有依据、有边界、有恢复机制。只有当成果能够验收、问题能够定位、风险能够控制，智能体才可能从辅助功能成长为稳定的业务工具。