大模型应用正在经历一次重要转变。早期产品主要围绕“对话”展开用户提出问题模型生成答案。随着工具调用、代码执行、外部系统连接和多智能体协作逐渐成熟越来越多的产品开始尝试让模型完成真正的任务例如分析复杂资料、制定执行计划、调用业务系统、持续跟踪进度并交付可验证的成果。但从“生成答案”走向“执行任务”并不是简单地给大模型增加几个工具。当任务执行时间从几分钟延长到几小时甚至几天当执行过程涉及多个系统、多个参与者、共享资源和高风险操作时传统的对话式 Agent 架构就会暴露出明显问题模型上下文可能被压缩或丢失工具调用可能重复执行多个 Agent 可能产生冲突外部系统状态可能在执行期间发生变化模型可能错误地认为任务已经完成某些操作一旦执行无法简单撤销用户很难理解任务当前进行到了哪里。因此复杂任务产品真正需要建设的不是一个“更会聊天的 Agent”而是一套围绕任务生命周期运行的智能体运行时。一、Agent 是执行手段Task 才是产品核心许多多智能体系统把 Agent 作为最重要的对象系统中有研究 Agent、规划 Agent、执行 Agent、审核 Agent它们通过对话共同完成任务。这种设计适合实验和原型但并不适合直接承担生产任务。因为在真实业务中用户真正关心的不是“哪个 Agent 在线”而是任务目标是什么当前进行到哪一步哪些条件已经满足哪些资源正在被占用哪些操作等待审批为什么任务暂停或失败最终结果是否真实可信。因此产品的权威对象应该是 Task而不是 Agent也不是聊天会话。一个完整的任务至少应包含目标 约束 优先级 风险等级 执行计划 当前状态 资源占用 待审批事项 执行记录 成果文件 验收证据 异常与未完成项Agent 可以参与理解目标、生成计划、分析异常和整理结果但不能直接决定任务已经成功也不能任意修改任务状态。成熟的架构应把不稳定的模型推理封装在稳定的任务协议中模型负责提出候选方案任务运行时负责状态控制执行网关负责提交动作评估模块负责验证结果。二、对话上下文不是任务状态Claude Code、Codex 等智能体产品带来的一个重要启示是长任务不能依赖一次连续对话。模型上下文只是某次推理所看到的信息集合。它可能因为窗口限制被压缩也可能因为会话中断、进程迁移或模型切换而丢失。如果任务进度只保存在聊天记录中就会出现几个问题新会话无法准确恢复任务摘要可能遗漏关键约束工具已经执行但模型忘记了执行结果多个 Agent 对任务进度产生不同理解系统难以进行一致性校验和审计。因此应将以下信息保存在外部结构化状态中已经完成的步骤 当前执行步骤 尚未满足的依赖 正在持有的资源 最近发生的失败 缺失的验收证据 下一步建议动作 计划和配置版本即使模型会话终止新的执行实例也可以根据任务状态和进度产物继续运行而不是依靠完整聊天记录恢复。这里可以形成一个重要原则上下文用于推理状态用于续跑上下文可以被重建权威状态不能丢失。三、不是所有任务都应该使用 Agent当前不少产品存在一种倾向只要接入了大模型就试图把所有流程都改造成 Agent。实际上任务应该根据确定性和开放程度选择不同执行方式。1. 普通函数适合明确的查询、转换和计算。例如数据格式转换、规则匹配、指标计算不需要模型参与。2. 规则或工作流适合步骤已经明确、顺序和条件稳定的任务。例如固定审批流程、标准数据同步、周期性报表生成。3. 单 Agent适合目标明确但解决路径需要根据上下文动态判断的任务。例如资料分析、方案生成、异常原因研判。4. Agent 加工作流适合既需要模型推理又要求可靠执行的任务。模型负责判断和规划工作流负责状态、重试、审批和恢复。这通常是复杂业务任务最实用的模式。5. 多 Agent只有当任务能够清晰并行拆分、共享状态较少、协调收益高于额外成本时才值得启用多 Agent。因此系统应先判断“是否需要 Agent”再判断“是否需要多个 Agent”。设计中明确提出开放目标可以使用 Agent明确步骤应使用 Workflow确定性问题优先使用普通函数多 Agent 仅在并行收益明确且资源冲突可控时启用。四、动态规划不等于自由执行大模型擅长理解模糊目标、发现未知项、比较方案和生成候选计划。但模型生成的自然语言步骤不能直接执行。在正式执行之前计划需要经过一次“编译”。一个候选计划通常要完成以下处理自然语言计划 → 实体和动作标准化 → 依赖关系解析 → 工具和执行能力匹配 → 资源绑定 → 风险分级 → 前置条件检查 → 规则和流程校验 → 必要的模拟验证 → 生成不可变计划版本最终进入执行系统的不应是一段模型文本而应是一份结构化计划。这种模式可以概括为动态认知规划确定性计划控制受约束动作执行。模型可以提出“建议做什么”但是否允许执行、由谁执行、使用哪些资源、是否需要审批以及任务状态如何迁移都应由确定性运行时决定。五、工具接入不等于安全执行工具协议和外部系统连接能力解决的是“如何调用”但没有解决“是否应该调用”。一个生产级执行网关需要在动作真正提交之前完成多层检查输入参数是否合法当前 Agent 是否具备相应能力发起任务的用户是否授权动作是否符合业务规则前置条件是否满足所需资源是否已经取得租约是否需要人工审批是否存在重复提交凭证是否在有效期和权限范围内执行结果需要采集哪些证据。因此Agent 不应直接持有生产系统的长期凭证。更安全的方式是由凭证服务在动作通过校验后签发仅对当前操作有效的短期权限。系统也应区分不同类型的副作用只读操作 可撤销写操作 可补偿操作 事务型操作 物理操作 不可逆操作对于不可逆或高风险操作不能依赖模型判断必须设置人工审批、外部联锁或明确的接管机制。六、任务成功必须由证据证明对话型 Agent 最常见的风险之一是模型根据自己的输出判断任务已经完成。例如模型生成了一份报告不代表真实问题已经解决接口返回成功也不一定代表下游业务状态已经正确更新。复杂任务的完成应满足三个条件计划步骤已经执行 后置条件已经满足 验收证据完整且通过验证证据可以来自外部系统的最新状态业务事务号和回执设备执行信号日志和监控指标图片、文件或检测结果人工签名和审批记录仿真或确定性规则的校验结果。模型可以对证据进行解释和总结但不能单独充当高风险任务的最终验收器。原设计将任务成功明确绑定到验收标准、外部状态、Evidence 和 Evaluator而不是模型自我声明。七、记忆不能自动变成规则Agent 在执行任务过程中会积累大量经验例如某种异常的处理方式、某个工具的使用技巧或者某类失败的常见原因。这些信息有价值但不能自动成为正式规则。更合理的记忆和知识结构应分为多个层级工作上下文 当前步骤需要的信息 任务状态 计划、资源、审批和证据等权威数据 任务经历 某次任务的过程和结果 候选知识 模型总结但尚未验证的经验 审核知识 经过验证和发布的可复用知识 正式规则 能够约束任务执行的强制策略候选经验需要经过证据关联、适用范围识别、冲突检测、离线测试、领域审核和版本发布才能晋级为正式知识或规则。这可以避免一次错误推理被长期记忆并在后续任务中持续放大。八、多 Agent 的重点是隔离而不是群聊多 Agent 系统经常被设计成多个角色在同一个群聊中轮流发言。这种方式直观但很容易产生重复工作、上下文膨胀、责任不清和结果冲突。更有效的多 Agent 模式应强调子任务边界明确每个 Worker 拥有独立上下文共享状态尽量只读中间成果写入独立产物空间Agent 返回结构化结果或引用而不是全部思考过程最终结果由统一模块校验和合并Agent 不得直接并发修改权威业务状态。因此多 Agent 更接近“隔离的并行工作单元”而不是“多个模型自由开会”。对于共享资源密集、步骤高度串行或存在物理冲突的任务单 Agent 加确定性工作流通常更加可靠。九、复杂任务产品需要“驾驶舱”而不是只有聊天框当任务持续较长时间时聊天记录并不是最合适的用户界面。用户需要看到的是一个任务驾驶舱包括任务目标和当前状态 计划版本和步骤依赖 当前执行者 资源占用 风险和待审批事项 异常与阻塞 成果文件 证据完整度 执行成本和耗时 暂停、重规划和接管入口聊天区仍然重要但它的职责应转变为解释当前状态向用户询问缺失信息接收约束调整提供决策建议接受暂停、修改和接管命令。也就是说聊天是人机协作入口任务驾驶舱才是复杂工作的主要载体。十、从建议型自动化开始而不是一步到位复杂任务系统的自动化能力应逐步开放。可以采用三个阶段第一阶段建议型系统读取数据、分析问题、生成计划和报告但不执行生产写操作。第二阶段半自动系统可以创建待审批动作由用户确认后执行并自动采集结果和证据。第三阶段受控自动在边界明确、风险可控、证据充分、异常可接管的场景中系统可以自动完成部分操作。渐进式自动化比“一开始就追求全自主 Agent”更符合生产系统的安全和组织接受度。原方案同样将自动化路径定义为先建议型、再半自动最后只在可证明安全的范围内自动执行。结语大模型让系统拥有了理解模糊目标和生成解决方案的能力但复杂任务真正落地需要的远不止一个强大的模型。一个可靠的智能体任务平台应当同时具备稳定的任务生命周期结构化计划和状态机可恢复的长任务执行模型和工作流的合理分工受控的工具与系统接入多层权限和人工审批独立的执行环境资源仲裁与并发隔离证据驱动的任务验收可审计、可版本化的知识体系。未来智能体产品的竞争不会只取决于“模型能想多远”还取决于系统能否把模型的推理可靠地转化为真实、可控、可验证的结果。真正有价值的 Agent不只是能够回答问题。它需要能够在明确的边界中持续工作在遇到不确定性时主动求助在发生异常时安全停止并最终证明任务确实已经完成。
大模型应用正在经历一次重要转变。早期产品主要围绕“对话”展开用户提出问题模型生成答案。随着工具调用、代码执行、外部系统连接和多智能体协作逐渐成熟越来越多的产品开始尝试让模型完成真正的任务例如分析复杂资料、制定执行计划、调用业务系统、持续跟踪进度并交付可验证的成果。但从“生成答案”走向“执行任务”并不是简单地给大模型增加几个工具。当任务执行时间从几分钟延长到几小时甚至几天当执行过程涉及多个系统、多个参与者、共享资源和高风险操作时传统的对话式 Agent 架构就会暴露出明显问题模型上下文可能被压缩或丢失工具调用可能重复执行多个 Agent 可能产生冲突外部系统状态可能在执行期间发生变化模型可能错误地认为任务已经完成某些操作一旦执行无法简单撤销用户很难理解任务当前进行到了哪里。因此复杂任务产品真正需要建设的不是一个“更会聊天的 Agent”而是一套围绕任务生命周期运行的智能体运行时。一、Agent 是执行手段Task 才是产品核心许多多智能体系统把 Agent 作为最重要的对象系统中有研究 Agent、规划 Agent、执行 Agent、审核 Agent它们通过对话共同完成任务。这种设计适合实验和原型但并不适合直接承担生产任务。因为在真实业务中用户真正关心的不是“哪个 Agent 在线”而是任务目标是什么当前进行到哪一步哪些条件已经满足哪些资源正在被占用哪些操作等待审批为什么任务暂停或失败最终结果是否真实可信。因此产品的权威对象应该是 Task而不是 Agent也不是聊天会话。一个完整的任务至少应包含目标 约束 优先级 风险等级 执行计划 当前状态 资源占用 待审批事项 执行记录 成果文件 验收证据 异常与未完成项Agent 可以参与理解目标、生成计划、分析异常和整理结果但不能直接决定任务已经成功也不能任意修改任务状态。成熟的架构应把不稳定的模型推理封装在稳定的任务协议中模型负责提出候选方案任务运行时负责状态控制执行网关负责提交动作评估模块负责验证结果。二、对话上下文不是任务状态Claude Code、Codex 等智能体产品带来的一个重要启示是长任务不能依赖一次连续对话。模型上下文只是某次推理所看到的信息集合。它可能因为窗口限制被压缩也可能因为会话中断、进程迁移或模型切换而丢失。如果任务进度只保存在聊天记录中就会出现几个问题新会话无法准确恢复任务摘要可能遗漏关键约束工具已经执行但模型忘记了执行结果多个 Agent 对任务进度产生不同理解系统难以进行一致性校验和审计。因此应将以下信息保存在外部结构化状态中已经完成的步骤 当前执行步骤 尚未满足的依赖 正在持有的资源 最近发生的失败 缺失的验收证据 下一步建议动作 计划和配置版本即使模型会话终止新的执行实例也可以根据任务状态和进度产物继续运行而不是依靠完整聊天记录恢复。这里可以形成一个重要原则上下文用于推理状态用于续跑上下文可以被重建权威状态不能丢失。三、不是所有任务都应该使用 Agent当前不少产品存在一种倾向只要接入了大模型就试图把所有流程都改造成 Agent。实际上任务应该根据确定性和开放程度选择不同执行方式。1. 普通函数适合明确的查询、转换和计算。例如数据格式转换、规则匹配、指标计算不需要模型参与。2. 规则或工作流适合步骤已经明确、顺序和条件稳定的任务。例如固定审批流程、标准数据同步、周期性报表生成。3. 单 Agent适合目标明确但解决路径需要根据上下文动态判断的任务。例如资料分析、方案生成、异常原因研判。4. Agent 加工作流适合既需要模型推理又要求可靠执行的任务。模型负责判断和规划工作流负责状态、重试、审批和恢复。这通常是复杂业务任务最实用的模式。5. 多 Agent只有当任务能够清晰并行拆分、共享状态较少、协调收益高于额外成本时才值得启用多 Agent。因此系统应先判断“是否需要 Agent”再判断“是否需要多个 Agent”。设计中明确提出开放目标可以使用 Agent明确步骤应使用 Workflow确定性问题优先使用普通函数多 Agent 仅在并行收益明确且资源冲突可控时启用。四、动态规划不等于自由执行大模型擅长理解模糊目标、发现未知项、比较方案和生成候选计划。但模型生成的自然语言步骤不能直接执行。在正式执行之前计划需要经过一次“编译”。一个候选计划通常要完成以下处理自然语言计划 → 实体和动作标准化 → 依赖关系解析 → 工具和执行能力匹配 → 资源绑定 → 风险分级 → 前置条件检查 → 规则和流程校验 → 必要的模拟验证 → 生成不可变计划版本最终进入执行系统的不应是一段模型文本而应是一份结构化计划。这种模式可以概括为动态认知规划确定性计划控制受约束动作执行。模型可以提出“建议做什么”但是否允许执行、由谁执行、使用哪些资源、是否需要审批以及任务状态如何迁移都应由确定性运行时决定。五、工具接入不等于安全执行工具协议和外部系统连接能力解决的是“如何调用”但没有解决“是否应该调用”。一个生产级执行网关需要在动作真正提交之前完成多层检查输入参数是否合法当前 Agent 是否具备相应能力发起任务的用户是否授权动作是否符合业务规则前置条件是否满足所需资源是否已经取得租约是否需要人工审批是否存在重复提交凭证是否在有效期和权限范围内执行结果需要采集哪些证据。因此Agent 不应直接持有生产系统的长期凭证。更安全的方式是由凭证服务在动作通过校验后签发仅对当前操作有效的短期权限。系统也应区分不同类型的副作用只读操作 可撤销写操作 可补偿操作 事务型操作 物理操作 不可逆操作对于不可逆或高风险操作不能依赖模型判断必须设置人工审批、外部联锁或明确的接管机制。六、任务成功必须由证据证明对话型 Agent 最常见的风险之一是模型根据自己的输出判断任务已经完成。例如模型生成了一份报告不代表真实问题已经解决接口返回成功也不一定代表下游业务状态已经正确更新。复杂任务的完成应满足三个条件计划步骤已经执行 后置条件已经满足 验收证据完整且通过验证证据可以来自外部系统的最新状态业务事务号和回执设备执行信号日志和监控指标图片、文件或检测结果人工签名和审批记录仿真或确定性规则的校验结果。模型可以对证据进行解释和总结但不能单独充当高风险任务的最终验收器。原设计将任务成功明确绑定到验收标准、外部状态、Evidence 和 Evaluator而不是模型自我声明。七、记忆不能自动变成规则Agent 在执行任务过程中会积累大量经验例如某种异常的处理方式、某个工具的使用技巧或者某类失败的常见原因。这些信息有价值但不能自动成为正式规则。更合理的记忆和知识结构应分为多个层级工作上下文 当前步骤需要的信息 任务状态 计划、资源、审批和证据等权威数据 任务经历 某次任务的过程和结果 候选知识 模型总结但尚未验证的经验 审核知识 经过验证和发布的可复用知识 正式规则 能够约束任务执行的强制策略候选经验需要经过证据关联、适用范围识别、冲突检测、离线测试、领域审核和版本发布才能晋级为正式知识或规则。这可以避免一次错误推理被长期记忆并在后续任务中持续放大。八、多 Agent 的重点是隔离而不是群聊多 Agent 系统经常被设计成多个角色在同一个群聊中轮流发言。这种方式直观但很容易产生重复工作、上下文膨胀、责任不清和结果冲突。更有效的多 Agent 模式应强调子任务边界明确每个 Worker 拥有独立上下文共享状态尽量只读中间成果写入独立产物空间Agent 返回结构化结果或引用而不是全部思考过程最终结果由统一模块校验和合并Agent 不得直接并发修改权威业务状态。因此多 Agent 更接近“隔离的并行工作单元”而不是“多个模型自由开会”。对于共享资源密集、步骤高度串行或存在物理冲突的任务单 Agent 加确定性工作流通常更加可靠。九、复杂任务产品需要“驾驶舱”而不是只有聊天框当任务持续较长时间时聊天记录并不是最合适的用户界面。用户需要看到的是一个任务驾驶舱包括任务目标和当前状态 计划版本和步骤依赖 当前执行者 资源占用 风险和待审批事项 异常与阻塞 成果文件 证据完整度 执行成本和耗时 暂停、重规划和接管入口聊天区仍然重要但它的职责应转变为解释当前状态向用户询问缺失信息接收约束调整提供决策建议接受暂停、修改和接管命令。也就是说聊天是人机协作入口任务驾驶舱才是复杂工作的主要载体。十、从建议型自动化开始而不是一步到位复杂任务系统的自动化能力应逐步开放。可以采用三个阶段第一阶段建议型系统读取数据、分析问题、生成计划和报告但不执行生产写操作。第二阶段半自动系统可以创建待审批动作由用户确认后执行并自动采集结果和证据。第三阶段受控自动在边界明确、风险可控、证据充分、异常可接管的场景中系统可以自动完成部分操作。渐进式自动化比“一开始就追求全自主 Agent”更符合生产系统的安全和组织接受度。原方案同样将自动化路径定义为先建议型、再半自动最后只在可证明安全的范围内自动执行。结语大模型让系统拥有了理解模糊目标和生成解决方案的能力但复杂任务真正落地需要的远不止一个强大的模型。一个可靠的智能体任务平台应当同时具备稳定的任务生命周期结构化计划和状态机可恢复的长任务执行模型和工作流的合理分工受控的工具与系统接入多层权限和人工审批独立的执行环境资源仲裁与并发隔离证据驱动的任务验收可审计、可版本化的知识体系。未来智能体产品的竞争不会只取决于“模型能想多远”还取决于系统能否把模型的推理可靠地转化为真实、可控、可验证的结果。真正有价值的 Agent不只是能够回答问题。它需要能够在明确的边界中持续工作在遇到不确定性时主动求助在发生异常时安全停止并最终证明任务确实已经完成。
