大模型任务执行能力的演进：从单轮问答到端到端交付

一、从“回答问题”到“完成任务”

过去使用大模型，多数场景是输入一个问题，得到一段文字回答。这种交互模式的边界很清楚：模型的输出是一段文本，后续的查证、整理、执行和验收都由人完成。

新一代模型的重点正在转移。用户给出的不再是单个问题，而是一个完整目标，例如“核对某项政策的最新条款，整理对比表，写成内部说明文档，并附上引用来源”。完成这样的目标需要多个步骤：拆解子任务、检索信息、读取文件、执行计算或代码、校验结果、生成最终材料。模型需要在整个过程中保持目标一致，并对每一步的结果做出判断。

这一转变带来的评估标准也随之变化。单纯看一次回答是否流畅已经不够，还要看任务的完成率、中间步骤的正确率、人工修正的次数，以及最终交付物能否直接使用。

二、长链条任务的四个技术环节

一个可靠的任务执行系统通常包含四个环节。每个环节都可能成为失败点，因此需要分别设计和验证。

2.1 目标分解与规划

规划模块负责把高层目标拆成可执行的子任务，并确定子任务之间的依赖关系。好的规划能让后续步骤有明确的输入和输出标准。

规划有两个常见问题。其一是拆分过粗，子任务内部仍包含多个判断，出错后难以定位。其二是拆分过细，流程变得冗长，调用成本和耗时明显上升。实践中，较稳妥的做法是让每个子任务只产生一个可验证的中间产物，例如一份数据表、一段代码或一个检索结果列表。

2.2 工具调用

模型本身无法直接访问外部世界，需要通过工具完成检索、读写文件、执行代码、操作浏览器或调用业务接口。工具调用的通用流程如下：

1. 模型根据当前状态选择工具，并生成结构化参数；
2. 运行时校验参数，检查权限，然后执行调用；
3. 工具返回结果，运行时将其整理成模型可读的观察信息；
4. 模型基于观察信息决定下一步动作。

工具层需要承担边界控制的职责。参数校验、超时设置、结果截断、错误码标准化都应在运行时完成，而不是交给模型自行判断。

2.3 过程中的状态管理与纠偏

长任务往往需要数分钟甚至更久，过程中可能出现工具超时、网页结构变化、中间结果与预期不符等情况。系统应当保存任务状态，并允许在任务中途插入新的指令或修正目标。

常见的做法包括：

• 用状态机记录每个子任务的状态，例如待执行、执行中、已完成、失败、待人工确认；
• 对耗时工具采用异步调用，主流程通过回调或轮询获取结果，避免阻塞整个任务；
• 在关键节点设置检查点，失败后从最近的检查点恢复，而不是从头开始。

纠偏能力依赖于状态的可见性。如果系统只输出最终结果，用户无法判断中间哪一步出了问题。因此，过程日志和中间产物应当可查询。

2.4 结果校验与交付物生成

交付环节要求系统输出可直接使用的成品，并附带依据。校验可以分为三层：格式校验，例如表格列数、文件能否打开；内容校验，例如数字是否与来源一致、引用是否真实存在；业务校验，例如是否满足预设的规则和合规要求。

自动校验无法覆盖所有问题，关键结论仍需要人工复核。系统的价值在于把人工复核的范围缩小到少数高风险点。

下面是一段示意性的伪代码，展示任务循环的基本结构：

function run_task(goal):
    plan = make_plan(goal)                 # 拆解为子任务
    checkpoint = init_state(plan)
    while not all_done(plan):
        step = next_ready_step(plan)
        if step.requires_human_review:
            pause_and_ask(step)
            continue
        args = build_args(step, checkpoint)
        check_permission(step.tool, args)  # 最小权限校验
        result = call_tool(step.tool, args, timeout=T)
        if result.error:
            retry_or_mark_failed(step, result)
        else:
            checkpoint = save_state(step, result)
            verify(step, result)           # 格式与内容校验
    return assemble_deliverable(checkpoint)

这段代码省略了具体实现，重点在于流程结构：规划、权限检查、超时控制、检查点保存和校验各自独立，任何一环失败都不会静默扩散。

三、对开发者的影响：工作流设计要点

对开发者而言，任务型系统改变的是接口设计和工程组织方式。以下几点值得优先考虑。

任务边界要显式定义。 每个任务应声明输入、输出、可用工具和终止条件。边界越清楚，模型越不容易越权或偏离目标。

权限采用最小化原则。 模型只获得完成当前任务所需的权限。写入类、删除类、发送类操作应单独授权，并在执行前进行确认。

日志必须可审计。 每一次工具调用的入参、出参、耗时和执行者都应记录。日志既用于排错，也用于事后追溯责任。

人机协作节点要前置设计。 对于不可逆操作和高风险结论，应在流程中预留审批节点，而不是事后补救。

四、企业落地的评估框架

企业引入任务型系统前，建议建立一套可重复的评估方法，避免只凭演示效果做决策。

评估维度	说明	观测方式
任务完成率	无需人工介入即可交付的任务比例	按任务类型分组统计
中间正确率	子步骤结果与标准答案的一致程度	抽样复核
人工修正成本	每个任务平均需要修改的次数与时长	记录修改日志
端到端耗时	从提交到交付的总时间	链路追踪
单位成本	每个任务的计算与工具调用开销	按调用量核算

评估集应由真实业务任务构成，并覆盖正常场景、边界场景和异常场景。每次模型或工作流调整后，都应在同一评估集上重跑，以便比较变化。

五、风险与治理

任务执行能力越强，潜在风险也越大。主要风险包括以下几类。

误差累积。 长链条中每一步都有小概率出错，多步叠加后最终结果可能偏离很远。应对方法是设置检查点和中间校验，并限制单次任务的步骤数。

越权操作。 工具被误调用可能导致数据被修改或删除。应采用沙箱环境执行高风险操作，并对写入类工具设置二次确认。

数据泄露。 任务过程中可能读取敏感文件或将内部数据发送至外部服务。应对数据做分级管理，并在工具层实施脱敏和出境审查。

结果可信度。 模型可能生成看似合理但缺乏依据的内容。交付物应附带来源，关键数字应可追溯到原始数据。

治理的核心是把能力与控制放在同一套流程中设计。能力越强的环节，越需要明确的权限边界和审计记录。

六、分阶段落地建议

建议按以下三个阶段推进，每个阶段都设定明确的退出标准。

第一阶段是选点验证。选择一到两个重复性强、结果易校验的任务，例如资料整理或报表生成，建立基线数据，并验证任务循环的稳定性。

第二阶段是流程固化。将验证通过的任务沉淀为标准化流程，补齐权限控制、日志与审批节点，并让业务人员参与验收标准的制定。

第三阶段是规模推广。在更多业务线复用流程模板，同时建立统一的评估看板和事故复盘机制，持续迭代规划策略与工具集合。

每个阶段都应当保留人工复核的兜底路径。在评估数据足够充分之前，把模型定位为辅助执行者，比直接让其替代人工判断更稳妥。