尧图网站建设 
很多 Agent Demo 的主链路是LLM 生成计划 → 调用工具 → 返回结果。这个模型适合演示却不足以支撑生产环境。只要任务跨越多个页面、接口或账号故障就会从“异常情况”变成“必然事件”。生产级 Agent 首先要改掉一个默认假设工具调用成功不等于业务目标已经完成。HTTP 200 可能只是请求被接收浏览器点击成功可能只代表事件被触发工具返回 success 也可能发生在文件仍在上传、后台校验尚未完成或二次确认弹窗尚未处理时。因此一个更准确的完成条件应当是task_completed action_executed business_result_exists result_matches_expectation side_effect_is_acceptable1. 先建立显式状态机不要让 Agent 仅依赖对话上下文“记住”进度。任务状态至少应包含{task_id:publish-20260812-001,goal:将文章预填到多个内容平台,current_step:upload_cover,completed_steps:[login_check,fill_title,fill_body],attempt:2,artifacts:{draft_id:...},last_error:null,requires_approval:true}状态机的价值不只是可观测而是让恢复策略有依据。页面刷新、进程重启或模型切换后系统仍然知道下一步该做什么。2. 用 Checkpoint 支持长任务恢复Checkpoint 应放在有业务意义的边界而不是每一个鼠标动作之后。例如登录状态确认完成草稿已经创建并拿到 draft_id图片上传完成并获得资源地址内容校验通过等待人工确认。恢复时先读取远端状态再决定继续、跳过还是回滚不能机械地重放全部动作。3. 重试之前先分类错误一个实用的分类方式是错误类型示例推荐策略瞬时错误超时、限流、网络抖动指数退避并增加随机抖动认证错误Token 失效、会话过期刷新凭证或进入重新登录流程输入错误标签无效、标题超长修正参数后重试环境变化DOM 改版、按钮消失重新感知页面并规划不确定结果请求超时但可能已提交先查询结果禁止直接重放高风险动作发布、付款、删除暂停并请求人工确认关键原则是不确定结果不能直接重试。否则最容易产生重复发布、重复下单或重复写入。4. 幂等必须是端到端的只给某个 API 加 idempotency key 还不够。Agent 的幂等范围应该覆盖整个业务任务为任务生成稳定 task_id在本地保存 task_id 与远端资源 ID 的映射每次产生副作用之前先查询目标是否已存在若结果存在且一致直接把步骤标记为完成若存在但不一致进入修复或人工确认而不是覆盖。5. 把 Verifier 从执行器里拆出来Planner 决定怎么做Executor 负责调用工具Verifier 则独立判断“目标是否实现”。例如发布内容后的验证不应只读取发布按钮的 toast而应该重新查询内容列表或后台接口并核对标题、作者、状态、发布时间、封面和唯一链接。expected: status DRAFT, title X, image_count 3 observed: status DRAFT, title X, image_count 2 verdict: FAILED repair: upload_missing_image - verify_again验证条件最好由确定性规则承担只有语义一致性、视觉质量等难以结构化的部分再交给模型判断。6. 人工确认是系统能力不是补丁可靠的 human-in-the-loop 至少要向人展示即将执行的动作、目标对象、关键参数、可能产生的副作用以及拒绝后系统会怎样处理。一个只弹出“是否继续”的确认框并不够。确认信息越完整用户越容易发现 Agent 的误解。7. 推荐的闭环架构Plan - Execute - Observe - Verify - passed: request approval / deliver - failed: classify error - repairable: repair - re-verify - uncertain: query remote state - high-risk: human review日志也应该围绕这个闭环记录任务 ID、步骤 ID、工具输入摘要、调用耗时、错误分类、重试次数、远端资源 ID、验证证据和人工决策。2026 年 Agent 平台的竞争重点已经明显从“能连接多少工具”转向“能否管理长任务与真实副作用”。后台执行、凭证刷新、审批、遥测、远程 MCP、工作区协作正在成为基础设施层能力。结论很简单生产级 Agent 不是一条更长的 Prompt而是一套带状态、可恢复、可验证、可审计的运行时系统。会执行只是开始能够证明自己完成了才算真正完成。参考资料https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api/https://openai.com/solutions/use-case/agents/https://openai.com/index/work-with-codex-from-anywhere/https://openai.com/index/running-codex-safely/ 生产级 Agent 可靠性设计：状态机、重试、Checkpoint 与 Verifier
很多 Agent Demo 的主链路是LLM 生成计划 → 调用工具 → 返回结果。这个模型适合演示却不足以支撑生产环境。只要任务跨越多个页面、接口或账号故障就会从“异常情况”变成“必然事件”。生产级 Agent 首先要改掉一个默认假设工具调用成功不等于业务目标已经完成。HTTP 200 可能只是请求被接收浏览器点击成功可能只代表事件被触发工具返回 success 也可能发生在文件仍在上传、后台校验尚未完成或二次确认弹窗尚未处理时。因此一个更准确的完成条件应当是task_completed action_executed business_result_exists result_matches_expectation side_effect_is_acceptable1. 先建立显式状态机不要让 Agent 仅依赖对话上下文“记住”进度。任务状态至少应包含{task_id:publish-20260812-001,goal:将文章预填到多个内容平台,current_step:upload_cover,completed_steps:[login_check,fill_title,fill_body],attempt:2,artifacts:{draft_id:...},last_error:null,requires_approval:true}状态机的价值不只是可观测而是让恢复策略有依据。页面刷新、进程重启或模型切换后系统仍然知道下一步该做什么。2. 用 Checkpoint 支持长任务恢复Checkpoint 应放在有业务意义的边界而不是每一个鼠标动作之后。例如登录状态确认完成草稿已经创建并拿到 draft_id图片上传完成并获得资源地址内容校验通过等待人工确认。恢复时先读取远端状态再决定继续、跳过还是回滚不能机械地重放全部动作。3. 重试之前先分类错误一个实用的分类方式是错误类型示例推荐策略瞬时错误超时、限流、网络抖动指数退避并增加随机抖动认证错误Token 失效、会话过期刷新凭证或进入重新登录流程输入错误标签无效、标题超长修正参数后重试环境变化DOM 改版、按钮消失重新感知页面并规划不确定结果请求超时但可能已提交先查询结果禁止直接重放高风险动作发布、付款、删除暂停并请求人工确认关键原则是不确定结果不能直接重试。否则最容易产生重复发布、重复下单或重复写入。4. 幂等必须是端到端的只给某个 API 加 idempotency key 还不够。Agent 的幂等范围应该覆盖整个业务任务为任务生成稳定 task_id在本地保存 task_id 与远端资源 ID 的映射每次产生副作用之前先查询目标是否已存在若结果存在且一致直接把步骤标记为完成若存在但不一致进入修复或人工确认而不是覆盖。5. 把 Verifier 从执行器里拆出来Planner 决定怎么做Executor 负责调用工具Verifier 则独立判断“目标是否实现”。例如发布内容后的验证不应只读取发布按钮的 toast而应该重新查询内容列表或后台接口并核对标题、作者、状态、发布时间、封面和唯一链接。expected: status DRAFT, title X, image_count 3 observed: status DRAFT, title X, image_count 2 verdict: FAILED repair: upload_missing_image - verify_again验证条件最好由确定性规则承担只有语义一致性、视觉质量等难以结构化的部分再交给模型判断。6. 人工确认是系统能力不是补丁可靠的 human-in-the-loop 至少要向人展示即将执行的动作、目标对象、关键参数、可能产生的副作用以及拒绝后系统会怎样处理。一个只弹出“是否继续”的确认框并不够。确认信息越完整用户越容易发现 Agent 的误解。7. 推荐的闭环架构Plan - Execute - Observe - Verify - passed: request approval / deliver - failed: classify error - repairable: repair - re-verify - uncertain: query remote state - high-risk: human review日志也应该围绕这个闭环记录任务 ID、步骤 ID、工具输入摘要、调用耗时、错误分类、重试次数、远端资源 ID、验证证据和人工决策。2026 年 Agent 平台的竞争重点已经明显从“能连接多少工具”转向“能否管理长任务与真实副作用”。后台执行、凭证刷新、审批、遥测、远程 MCP、工作区协作正在成为基础设施层能力。结论很简单生产级 Agent 不是一条更长的 Prompt而是一套带状态、可恢复、可验证、可审计的运行时系统。会执行只是开始能够证明自己完成了才算真正完成。参考资料https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api/https://openai.com/solutions/use-case/agents/https://openai.com/index/work-with-codex-from-anywhere/https://openai.com/index/running-codex-safely/