<![CDATA[AI Agent为什么容易烂尾：任务边界、状态、工具和验收]]>AI Agent 最容易给人一种错觉：只要模型足够强，给它一个目标，它就会自己规划、自己调用工具、自己修复错误、自己完成任务。演示时，这种感觉尤其强。用户说“帮我调研竞品并写报告”，Agent 搜索网页、整理要点、生成文档；用户说“帮我修这个 bug”，Agent 读代码、改文件、跑测试；用户说“帮我订一套旅行计划”，Agent 查信息、比较价格、列出行程。看起来像一个真正能干活的助手。

但到了真实产品和真实工作流里，Agent 很容易烂尾。它开始时很积极，中间做了很多动作，最后却停在一个半成品：报告有结构但证据不完整，代码改了一半但测试没跑通，表单填了一部分但没有提交，工单分析了原因但没有给可执行结论，工具调用失败后换了几个方向又绕回原点。表面看是模型不够聪明， deeper 的原因通常是系统没有把任务边界、状态、工具和验收设计清楚。

Agent 烂尾不是一个单点问题。它往往来自四类缺口：目标没有被拆成可完成任务，状态没有被可靠保存和更新，工具能力和现实环境之间有缝，验收标准没有变成可执行检查。模型可以推理，可以写计划，可以调用工具，但它不能凭空知道“做到什么算完成”，也不能替系统弥补权限、幂等、回滚、错误处理和人工确认的缺失。真正生产级的 Agent，不是一个长提示词加一堆工具，而是一套可恢复、可验证、可审计的任务执行系统。

一、Agent不是聊天机器人加工具列表

聊天机器人回答问题，主要目标是生成一段有帮助的文本。Agent 执行任务，目标是改变某种状态：文件被修改，订单被创建，报告被交付，数据被分析，客户被跟进，代码通过测试，知识库被更新。这个差别决定了 Agent 不能只按对话质量来设计。它要面对现实世界里的状态变化、权限边界、失败重试、用户确认和最终验收。

ReAct 论文把 reasoning 和 acting 结合起来，让模型一边思考一边行动，通过工具观察外部环境，再根据观察继续推理。Toolformer 讨论模型如何学习使用工具。后来的 WebArena、AgentBench、GAIA、SWE-bench 等评测进一步把 Agent 放进更真实的环境：网页、工具、软件仓库、复杂问题和多步任务。它们共同说明一个事实：Agent 能不能完成事，不只取决于模型语言能力，还取决于它如何和环境互动。

很多产品失败，是因为把 Agent 当成“会调用工具的聊天框”。系统给模型一堆工具说明，然后希望模型自己决定何时用、怎么用、用完怎么判断结果。这样可以做演示，但很难做生产。真实工具有权限、参数、速率限制、异常、并发冲突和副作用。模型如果没有明确任务状态和验收标准，很容易在“继续查一点”“再试一次”“重新总结一下”之间循环。

Agent 的核心不是自由，而是受控自治。它需要在明确边界内自主处理细节，在高风险动作前请求确认，在失败时保存现场，在完成时给出可验证结果。Anthropic 在关于有效 Agent 的文章中强调，很多场景中工作流和 Agent 应该区分：如果任务路径清楚，工作流更可靠；如果路径需要动态决策，Agent 才有价值。这个判断很关键，因为不是所有自动化都应该交给开放式 Agent。

所以，设计 Agent 的第一步不是写系统提示词，而是判断任务属于哪一类。固定流程适合 workflow，开放探索适合 Agent，人机协同适合半自动流程。把所有事情都包装成 Agent，会让简单任务变复杂，也会让复杂任务缺少控制。

二、烂尾的第一类原因：任务边界太虚

用户经常用自然语言描述目标：“帮我研究一下”“帮我优化一下”“帮我做完这个”“帮我看看哪里有问题”。人能从上下文里追问、确认、判断范围，Agent 如果没有边界管理，就会把这些话当作开放任务开始执行。开放任务最大的问题是没有明确终点。研究到什么深度算够？优化到什么指标算好？做完包含哪些文件、哪些测试、哪些提交？看看问题后要不要修？没有边界，Agent 只能用自己的猜测停下来。

任务边界至少包含五件事：输入范围、允许动作、完成物、质量标准和退出条件。输入范围说明 Agent 应该看哪些文件、哪些数据、哪些网页，哪些内容不要碰。允许动作说明它能读、能写、能调用、能提交、能删除还是只能建议。完成物说明最终要交付什么，是文档、代码、配置、表格、工单结论还是操作记录。质量标准说明结果要满足什么约束。退出条件说明什么时候可以停止，什么时候必须追问，什么时候必须交给人。

烂尾常发生在“目标很大但没有拆解”的任务里。比如“帮我重构这个模块”包含理解现有行为、识别边界、制定方案、改代码、迁移调用、写测试、跑回归、处理兼容、更新文档。Agent 如果只看到一句目标，可能先改一个明显文件，然后发现影响更大，接着继续读更多文件，最后上下文越来越乱。正确做法是把大任务拆成可验收阶段：先输出影响分析，再确认范围，再改最小闭环，再跑测试，再处理边界。

边界虚还会导致过度执行。用户只是想要分析，Agent 却直接改文件；用户只想改一个页面，Agent 顺手重构全局样式；用户想要草稿，Agent 却调用外部系统发送消息。Agent 的“积极”在生产里可能是风险。系统需要把动作分级：只读动作可以自动执行，低风险写入可以在沙盒里执行，高风险写入必须确认，不可逆动作必须有预览和回滚。

任务边界也要处理“不做什么”。很多提示词只写要做的事，不写禁区。生产任务里，禁区同样重要：不要修改无关文件，不要使用未授权数据，不要猜测缺失信息，不要提交未经测试的代码，不要把系统后台信息展示给用户，不要在证据不足时给确定结论。这些不是道德口号，而是验收条件。

边界管理最实用的形态，是让 Agent 在开始前生成任务契约。契约不需要冗长，但要明确：目标、范围、步骤、交付物、需要用户确认的点、验收方式。对简单任务，契约可以自动生成并立即执行；对复杂或高风险任务，应先让用户确认。这样做不是降低智能，而是让智能有目标。

三、烂尾的第二类原因：状态没有被当成一等对象

Agent 执行任务时，状态比文本更重要。它已经读过哪些文件，做过哪些判断，调用过哪些工具，哪些步骤成功，哪些失败，用户确认了什么，当前阻塞在哪里，下一步是什么，这些都属于状态。如果状态只存在模型上下文里，就很脆弱。上下文会变长，会被截断，会被压缩，会混入旧信息。模型一旦忘记或误读状态，就会重复劳动、漏步骤或错误收尾。

长任务尤其依赖状态。一次代码修复可能经历读取报错、定位模块、修改文件、跑测试、发现新错误、二次修改、再跑测试、总结风险。一次研究任务可能经历搜索资料、筛选来源、记录引用、比较观点、写作、事实检查、修订。每一步都产生中间结果。没有结构化状态，Agent 很容易在后半程丢失前面做过的决定。

LangGraph 的 persistence 和 checkpoint 设计之所以重要，是因为它把 Agent 执行过程中的状态保存下来，支持从中断点恢复、人工介入和长期运行。生产 Agent 需要类似能力。浏览器崩了、工具超时了、用户离开了、模型请求失败了，任务不应该从头开始，也不应该忘记已经执行的副作用。可恢复执行是 Agent 从演示走向生产的分水岭。

状态还要区分事实、假设和计划。很多 Agent 烂尾，是因为把计划当事实。模型说“接下来我会运行测试”，并不等于测试已经运行；模型说“问题可能在缓存”，并不等于根因确认；模型说“已经修复”，如果没有执行验证，就只是声明。状态系统应记录每一步的证据：工具返回、文件 diff、测试结果、网页截图、用户确认、外部接口响应。

状态也要处理版本。Agent 读到的文件可能被用户或其他进程修改，网页内容可能变化，数据库记录可能更新，工单状态可能被同事处理。如果 Agent 用旧状态继续行动，就会覆盖别人工作或输出过期结论。生产系统需要在关键写入前检查版本、时间戳或 ETag，发现冲突时停下来而不是盲写。

还有一种常见烂尾来自多目标状态混杂。用户先让 Agent 查资料，后面又让它写文章，再让它顺手改标题。如果系统没有把当前任务和历史任务分开，模型会把旧目标、旧约束和新要求混在一起。多轮 Agent 应该维护任务栈或任务记录，把当前目标、已完成事项和开放问题清楚分离。

状态设计的原则很简单：重要信息不要只放在自然语言对话里。任务 ID、阶段、步骤、工具调用、文件改动、外部副作用、用户确认、阻塞原因、验收结果，都应该结构化记录。模型可以阅读这些状态，也可以更新这些状态，但不能把状态完全托付给一次上下文窗口。

四、烂尾的第三类原因：工具只是“能调用”，不是“能完成”

很多 Agent 系统把工具接入当作完成了一半：有搜索工具、浏览器工具、文件工具、数据库工具、邮件工具、日历工具、代码执行工具。实际上，工具能调用不等于工具能支撑任务完成。工具如果没有清晰输入输出、没有错误语义、没有幂等设计、没有权限控制、没有结果校验，模型调用得越多，风险越大。

一个好工具应该像面向 Agent 的产品接口，而不是把内部 API 原样暴露给模型。它的名称要表达动作，参数要少而清晰，返回结果要面向任务，错误要可恢复。比如搜索工具不应该只返回一大段 HTML，而应返回标题、链接、发布时间、摘要、来源可信度和可继续打开的句柄。数据库工具不应该把所有字段裸露出来，而应返回任务相关字段和权限范围。代码工具不应该只说“失败”，而应返回命令、退出码、关键错误和下一步建议。

工具烂尾常见于错误处理。模型调用工具失败后，如果错误信息模糊，它可能反复尝试同一个错误参数，或者换一个无关方向。工具应该把错误分成参数错误、权限错误、资源不存在、网络超时、速率限制、冲突、不可逆风险等类型，并告诉 Agent 哪些错误可以重试，哪些必须修改输入，哪些需要用户授权，哪些应该停止。

工具还要有幂等性。Agent 常常会因为不确定、超时或上下文恢复而重复调用工具。如果工具是“创建订单”“发送邮件”“删除文件”“提交审批”这种有副作用的动作，重复调用可能造成真实损失。生产工具应支持 idempotency key、预演模式、确认步骤和操作记录。模型不应靠记忆来避免重复副作用，系统要从工具层防住。

工具权限也不能交给提示词。不能只在系统提示词里写“不要访问无权限数据”。工具层必须根据用户身份、任务上下文和业务规则做权限判断。Agent 看到的工具应该是当前用户可用的工具，工具返回的内容应该是当前用户可见的内容。否则模型一次错误调用就可能越权。

工具结果要可验证。搜索结果要能打开来源，文件修改要能展示 diff，代码执行要能返回测试输出，业务操作要有记录编号，数据分析要有查询和计算过程。Agent 最终回答“我已经完成”时，应该能附带证据，而不是只给自然语言承诺。

工具设计还有一个容易忽略的问题：粒度。工具太细，Agent 需要做大量低层决策，容易迷路；工具太粗，Agent 看不到关键过程，无法修复失败。合理做法是为常见高价值任务提供任务级工具，同时保留必要的低层工具用于诊断。例如“运行项目测试并摘要失败”比裸 shell 更适合作为常用工具，“读取指定文件片段”比一次性暴露整个仓库更安全。

五、烂尾的第四类原因：验收没有自动化

Agent 最后一步最容易出问题。它做了很多动作后，需要判断是否完成。没有验收标准时，模型会用语言收尾：“已完成”“问题已修复”“报告如下”“可以上线”。这些话不等于结果有效。生产系统里，完成必须有证据。

验收要尽量靠外部事实。代码任务要跑测试、类型检查、lint 或至少执行复现用例；RAG 答案要检查引用是否存在、关键事实是否被证据支持；数据任务要校验行数、公式、异常值和可复算性；表单任务要确认提交成功编号；网页操作要有页面状态或截图；文档任务要检查字数、结构、引用和重复段落。能程序化检查的，不要交给模型自评。

没有自动验收，Agent 很容易“看起来完成”。比如它修了一个函数，但没跑测试；它写了一篇调研报告，但引用来源只有标题没有链接；它整理了表格，但数值没有对齐原始数据；它完成了浏览器操作，但页面其实卡在登录页；它生成了计划，但没有任何下一步执行。用户看到完整文字，容易误以为任务完成，直到真正使用时发现半成品。

验收还要覆盖负面条件。不是只检查有没有输出，还要检查有没有触碰禁区。代码任务要看是否修改无关文件、是否引入敏感信息、是否删除用户改动；业务操作要看是否越权、是否重复提交、是否跳过审批；文档写作要看是否出现面向系统维护者的旁白、无来源断言、过期信息；客服任务要看是否承诺不能承诺的内容。

Agent 的验收可以分层。第一层是硬检查，程序可以确定通过或失败。第二层是模型评审，适合开放内容质量。第三层是人工确认，适合高风险动作。不要让所有任务都等人工，也不要让所有任务都自动通过。风险越高，验收越严格。

验收失败后的处理也很重要。很多 Agent 烂尾不是因为第一次失败，而是失败后不知道怎么恢复。测试失败后要读取关键错误并尝试最小修复；引用缺失后要回到资料检索；权限不足后要请求授权；信息不足后要向用户追问；超过重试次数后要交付当前状态和明确阻塞原因。失败恢复应该是流程的一部分，而不是模型临场发挥。

一个实用规则是：不要允许 Agent 只用自然语言宣布完成。它必须提供完成物和验收证据。证据可以是测试输出、链接、文件路径、操作编号、引用清单、截图、差异摘要或人工确认记录。没有证据，就只能叫“草稿”或“建议”，不能叫完成。

六、长上下文不是状态管理

很多人以为上下文窗口越来越长，Agent 烂尾问题会自然缓解。长上下文确实有帮助，模型可以看到更多历史、更多文件、更多资料。但长上下文不是状态管理。把所有对话、工具结果、网页内容和文件片段都塞进窗口，只会把任务历史变成一个难以检索的仓库。

长上下文有三个问题。第一，重要信息可能被淹没。Lost in the Middle 等研究提醒，模型不总能均匀使用长输入中的信息。第二，旧信息会和新信息冲突。任务中途用户改了目标，旧计划仍在上下文里，模型可能混用。第三，成本和延迟会上升。Agent 每一步都带着庞大历史，会让简单动作变慢。

生产 Agent 应该把上下文和状态分工。上下文提供当前推理所需材料，状态保存任务事实和执行进度。模型每一步不必看到全部原始历史，只需要看到当前目标、相关证据、已确认决策、待办事项和最近失败。完整日志可以留存供追溯，但不应该每次都塞给模型。

摘要也不能随便做。普通对话摘要可能丢掉关键约束，例如“不要修改某个文件”“这个测试失败可忽略”“用户已经确认方案 B”。Agent 状态摘要应该结构化：目标、范围、已完成、未完成、阻塞、用户确认、外部副作用、风险和下一步。摘要本身也要可更新、可审计。

如果任务跨越多次会话，状态更重要。用户隔天回来问“继续昨天那个任务”，Agent 不能只靠聊天记录猜。它需要知道昨天的任务 ID、最新文件版本、已跑过哪些测试、哪些问题未解决、用户最后确认了什么。没有持久状态，跨会话 Agent 基本只能重新开始。

长上下文的正确用法，是在需要时调取相关材料，而不是作为一切记忆的垃圾桶。它适合阅读长文档、比较资料、理解代码片段，但不适合替代任务数据库、事件日志、检查点和权限系统。

七、计划不是执行，执行不是完成

Agent 很擅长写计划，这也是它最容易欺骗人的地方。一个结构清晰的计划看起来像进展，但计划本身没有改变现实状态。用户要的是代码修好、资料查完、文件生成、问题关闭，不是一个漂亮流程图。Agent 系统必须区分计划、执行和完成。

计划阶段应该回答“打算怎么做”。它可以包含任务拆解、风险点、需要工具、需要确认的动作。执行阶段应该产生外部证据，例如读取文件、调用接口、写入文档、运行命令。完成阶段应该通过验收，并把结果交付给用户。三者混在一起时，Agent 会出现“写了很多步骤，但没真正做”的烂尾。

执行也不等于完成。运行了搜索，不等于完成调研；修改了代码，不等于修复 bug；调用了提交接口，不等于业务成功；生成了文档，不等于文档可用。每个执行动作后都要判断它是否推动任务接近验收。如果动作没有产生有效证据，就只是活动，不是进展。

生产系统可以用状态机约束这一点。任务从待澄清、已确认、执行中、待验收、已完成、已阻塞、已取消等状态流转。模型可以建议状态变化，但关键状态变化需要证据。比如从执行中进入已完成，必须有验收结果；从待澄清进入执行中，必须有足够任务边界；从待确认进入执行中，必须有用户确认。

这种状态机并不会削弱 Agent。相反，它让 Agent 有更清晰的行动空间。模型负责处理不确定性和复杂推理，系统负责确保每一步有位置、有记录、有退出条件。没有状态机，Agent 看起来更自由，但也更容易游荡。

八、人类介入不是失败，而是产品能力

很多 Agent 设计把人工介入当作失败路径，仿佛真正智能就应该全自动。生产场景恰恰相反：恰当的人类介入是可靠性的组成部分。高风险动作、信息不足、权限缺失、价值判断、不可逆操作，都应该让人确认。一个知道何时停下来问人的 Agent，比一个自信乱做的 Agent 更可用。

人类介入要设计得具体。不要只弹一句“需要确认吗”。应该展示将要执行的动作、影响范围、可选方案、风险和回滚方式。比如代码 Agent 在大范围修改前展示文件列表和改动意图；邮件 Agent 在发送前展示收件人、主题、正文和附件；业务 Agent 在提交审批前展示字段差异和依据。用户确认的是具体动作，不是抽象信任。

人工介入也要进入状态。用户确认了什么、拒绝了什么、修改了什么，都应被记录。否则下一步模型可能忘记用户刚刚否定的方案。人类反馈不是聊天噪声，而是任务状态的一部分。

还要避免把所有问题都推给用户。低风险、可验证、可回滚的动作应该自动完成。频繁确认会让 Agent 失去效率，用户也会机械点击。关键是风险分级：只读自动，草稿自动，可回滚写入可批量确认，不可逆和外部影响动作必须确认。

Anthropic 关于有效 Agent 的观点中，有一个重要判断：能用简单 workflow 解决的问题，就不要强迫模型每一步都自由决策。人类介入也类似。需要人判断的地方让人判断，不需要人判断的地方系统自动推进。好的 Agent 产品不是“全自动”或“全人工”，而是在正确位置切换控制权。

九、Agent评测必须评任务完成率

Agent 的评测不能停留在回答质量。它要看任务完成率。WebArena 把 Agent 放进真实风格的网站环境中完成任务，SWE-bench 用真实 GitHub issue 和仓库测试模型解决软件问题，GAIA 强调需要推理、工具使用和多步骤能力的问题。这些评测共同说明：Agent 的关键指标是能否在环境中完成目标，而不是单轮文本是否好看。

任务完成率也要拆分。一个任务失败，可能是理解错目标，可能是工具调用错，可能是状态丢失，可能是权限不足，可能是验收没过，可能是超时，也可能是模型在某一步推理失败。只记录“失败”没有改进价值。生产 Agent 应该记录失败阶段和失败原因。

Agent 评测集要包含真实长尾。简单任务只会证明演示可行。真正有用的评测应该包括模糊需求、缺失信息、工具报错、页面变化、文件冲突、权限限制、部分成功、需要追问、需要回滚等情况。Agent 是否能优雅处理这些情况，比顺风任务更能说明生产能力。

还要看效率。一个 Agent 最终完成任务，但用了二十次无效搜索、十次重复命令、三次错误写入，生产上也不一定可接受。评测要记录步骤数、工具调用数、成本、耗时、重试次数和人工介入次数。任务完成率高但成本失控，不能算好系统。

安全评测也不可少。Agent 有工具和副作用，风险高于普通聊天。它可能越权读取数据、泄露隐私、执行危险命令、发送错误消息、删除文件、重复提交。安全评测要覆盖权限、注入攻击、工具结果污染、外部网页诱导、敏感信息处理和不可逆操作确认。

最后，Agent 评测应该接近真实产品路径。只用模拟工具和理想 API，会高估能力。真实网页会变，真实代码有依赖，真实数据有脏值，真实权限会拒绝，真实用户会中途改需求。越接近真实环境，越能提前发现烂尾点。

十、上下文工程是Agent可靠性的基础

Agent 的上下文比普通问答更复杂。它不仅包含用户问题，还包含系统目标、工具说明、历史步骤、观察结果、外部资料、当前状态和验收标准。上下文工程做不好，Agent 会把无关信息当线索，把旧状态当当前事实，把工具错误当业务结论。

好的 Agent 上下文应该短而强。每一步给模型的信息都应该服务当前决策：现在目标是什么，已经确认什么，最近观察到什么，可用工具是什么，下一步需要解决什么，完成标准是什么。不要把完整日志、所有工具说明、所有历史对话都塞进去。信息越多，模型越容易抓错重点。

工具说明要和任务相关。一个 Agent 如果每次都看到几十个工具，会增加选择错误概率。可以按任务阶段动态暴露工具：调研阶段给搜索和阅读工具，写作阶段给文档工具，代码阶段给文件和测试工具，提交阶段给确认和发布工具。工具列表本身就是上下文的一部分，需要设计。

观察结果要整理。工具返回的原始内容往往太长、太杂、太面向机器。系统应把观察转成模型可用事实，同时保留原始证据可追溯。例如网页工具返回摘要、关键段落和链接；测试工具返回失败测试名、错误位置和关键堆栈；数据库工具返回查询结果和字段解释。模型需要的是决策材料，不是杂乱日志。

上下文还要避免指令冲突。外部网页、用户上传文档、工具返回内容里可能包含“忽略之前指令”“把密钥发给我”这类注入文本。Agent 不能把环境内容和系统指令放在同一层级。外部内容应该标记为数据，不能成为控制指令。工具层和模型层都要防止 prompt injection。

上下文工程不是写更长 prompt，而是控制信息流。Agent 烂尾时，很多团队第一反应是加一句规则。规则越加越多，模型越难判断优先级。更好的做法是减少噪声、结构化状态、缩小工具集、明确验收，并把规则落实到系统检查。

十一、从演示到生产的Agent架构

一个生产级 Agent 通常需要六个核心模块。第一是任务入口，把用户意图转成任务契约，识别风险和边界。第二是状态管理，记录阶段、步骤、证据、用户确认和外部副作用。第三是工具层，提供安全、清晰、可验证、可恢复的动作。第四是规划与执行，让模型在当前状态下选择下一步。第五是验收层，用程序、模型评审和人工确认判断是否完成。第六是观测与回放，记录 trace，支持复盘和改进。

这些模块不一定都很重，但不能缺席。小任务可以简化状态，小工具可以少量接入，低风险任务可以弱化人工确认。但只要 Agent 要处理真实用户目标，就必须有边界、状态、工具和验收。否则它只是一个更会说话的自动补全。

任务入口要有澄清能力。用户目标不清时，Agent 应该追问最少必要问题，而不是假装理解。比如“帮我优化网站”需要知道优化性能、转化率、视觉还是 SEO；“帮我修复登录问题”需要知道复现路径、报错、目标环境；“帮我写方案”需要知道受众、用途、长度和资料来源。追问不是能力不足，而是减少错误执行。

状态管理要支持恢复。任务中断后能继续，失败后能回滚到最近检查点，用户能看到当前进度。状态不是给开发者看的内部调试，而是支撑产品体验：用户知道 Agent 做到了哪里，为什么停住，还差什么。

工具层要做抽象。不要让模型直接面对所有内部接口。把高频任务封装成更安全的动作，把危险能力放在确认后，把返回结果变成可读证据。工具越接近用户任务，Agent 越容易完成。

验收层要有硬门槛。没有通过测试的代码不能说修好，没有引用的事实不能说确认，没有提交编号的外部操作不能说完成，没有用户确认的高风险动作不能执行。硬门槛会让 Agent 少说大话，多交证据。

观测与回放决定长期改进。每次失败都应该能看到任务契约、状态变化、工具调用、模型决策、验收结果和用户反馈。没有这些记录，团队只能看最终回答猜原因。Agent 系统越复杂，trace 越重要。

十二、不同场景的烂尾点

代码 Agent 常见烂尾是改了代码但不跑测试，跑了测试但不理解失败，修了一个文件却破坏另一个模块，或者在大型仓库里读太多无关文件。解决关键是限定修改范围、维护文件状态、运行真实测试、保留 diff、识别用户未授权改动，并在测试失败时做有证据的最小修复。

研究写作 Agent 常见烂尾是资料堆砌、引用不完整、来源质量不一、结论没有区分事实和观点。解决关键是优先权威来源，记录链接和发布时间，按问题组织证据，写作后做事实检查和重复检查。长文不是完成，来源和结构才是完成条件。

浏览器操作 Agent 常见烂尾是页面状态识别错误、弹窗或登录阻塞、表单填错、提交前没有复核、提交后没有确认编号。解决关键是让每一步读取页面状态，关键动作前截图或摘要，提交前展示字段，提交后确认成功页面或记录号。

客服 Agent 常见烂尾是解释很多但没有解决问题，或者在资料不足时给确定承诺。解决关键是把用户问题分类、检索最新政策、确认用户身份和权限、给出明确下一步，无法解决时准确转人工并携带上下文。

数据分析 Agent 常见烂尾是生成图表但计算不可复现，或者结论没有说明口径。解决关键是保存查询、清洗步骤、指标定义、异常处理和图表来源。分析结果要能被复算，否则只是文本。

企业流程 Agent 常见烂尾是绕过审批、重复提交、字段填错或缺少操作记录。解决关键是权限校验、预演、幂等、确认、提交回执和审计日志。流程 Agent 的可靠性来自制度化动作，不是模型自觉。

十三、怎样减少烂尾

第一，把用户目标转成可验收任务。不要让 Agent 直接从一句模糊话开始行动。目标、范围、交付物、禁区和验收方式越清楚，烂尾越少。

第二，把状态结构化保存。每一步做了什么、得到什么证据、下一步是什么、哪些事未完成，都要记录。长上下文只能辅助，不能替代状态。

第三，重新设计工具，而不是裸接 API。工具要任务化、权限化、可恢复、可验证。错误信息要让 Agent 知道下一步该怎么办。

第四，设置硬验收。代码要测试，资料要引用，操作要回执，文档要检查，风险动作要确认。不要允许自然语言自证完成。

第五，限制行动空间。按任务阶段暴露工具，按风险等级控制权限，按范围限制文件和数据。自由不是越大越好，边界清楚才更可靠。

第六，让 Agent 会停。资料不足时追问，权限不足时请求授权，风险过高时等确认，超过重试次数时交付阻塞原因。会停是生产能力。

第七，用真实任务评测。不要只看演示问题。把历史失败、边界案例、工具异常、权限限制和长任务放进评测集，记录任务完成率、成本和失败原因。

第八，把失败变成资产。每次烂尾都要进入复盘：边界是否不清，状态是否丢失，工具是否误导，验收是否缺失。修复系统，而不是只给提示词再补一句。

十四、Agent可靠性的最终判断

一个 Agent 是否可靠，不看它能不能写出漂亮计划，也不看它能不能连续调用很多工具，而看它能不能在真实边界内持续完成任务。它应该知道目标，知道当前状态，知道能用什么工具，知道什么时候需要人，知道完成标准，知道失败后怎么恢复。缺少这些，模型越强，行动越多，烂尾和误操作的风险也越大。

未来模型会继续变强，工具调用会更自然，长上下文会更便宜，Agent 框架会更成熟。但生产问题不会因此消失。任务边界、状态、工具和验收是工程基本盘。强模型可以让 Agent 更聪明，不能替代产品和系统设计。

真正可用的 Agent，最后给用户的不是“我正在处理”“我建议你可以”“我已经尝试”，而是清楚的完成物、可检查的证据、必要的风险提示和下一步选择。能把事情做到这里，才不容易烂尾。

十五、把Agent拆成可运营的服务

Agent 如果只被看成一次模型调用，就很难运营。真实产品里的 Agent 更像一个服务：有入口，有队列，有状态，有权限，有日志，有失败处理，有用户反馈，有成本预算。服务化之后，团队才能回答一些关键问题：今天完成了多少任务，失败最多发生在哪一步，哪些工具最常超时，哪些用户问题最容易卡住，哪些任务成本过高，哪些输出需要人工复核。

运营 Agent 的第一件事，是定义任务类型。不要把所有请求都扔进同一个大 Agent。调研、写作、代码修复、数据分析、表单操作、客服处理、知识库问答，各自需要不同工具、状态和验收。任务类型越清楚，系统越容易选择合适流程。低风险高频任务可以自动化更多，高风险低频任务可以保留更多人工确认。

第二件事，是设计任务队列。很多 Agent 任务不是即时完成的。长文档分析、代码修改、批量数据处理、网页调研都可能需要几十秒到几分钟。用户不应该盯着一个聊天气泡等待，也不应该在刷新页面后丢失进度。任务队列可以让 Agent 后台执行、保存进度、失败重试、通知用户，并支持暂停、取消和继续。

第三件事，是做成本控制。Agent 比普通聊天更容易烧成本，因为它会多轮思考、多次检索、多次工具调用、多次验证。没有预算，它可能为了一个低价值问题消耗大量 token 和外部调用。系统应该按任务设置预算：最大步骤数、最大工具调用数、最大搜索次数、最大执行时间、最大重试次数。预算用完后，Agent 应该总结已完成内容和阻塞原因，而不是无限循环。

第四件事，是收集用户反馈。用户说“有用”或“没用”只是粗粒度反馈，更有价值的是他们修改了哪里、采纳了哪些建议、拒绝了哪个动作、为什么转人工。反馈应该进入评测集和任务策略。Agent 产品不是一次设计完成，而是在真实任务中不断学习边界。

第五件事，是提供透明进度。透明不是展示模型内心独白，而是告诉用户当前处于哪个阶段：正在读取资料、正在核对证据、正在运行测试、等待确认、验收失败、需要补充信息。用户看到可靠进度，就能理解等待原因，也能在关键点介入。没有进度的 Agent，一旦耗时变长，用户会以为它卡住。

十六、Agent烂尾和组织流程有关

很多 Agent 烂尾并不完全是技术问题，而是组织没有把流程说清楚。企业里大量任务依赖隐性规则：谁能批准，哪个文件是准的，哪些字段必须填，哪些异常要升级，哪些操作不能在周五做，哪些客户需要特殊处理。人类员工通过培训和经验掌握这些规则，Agent 如果没有被明确告知，就只能猜。

因此，上 Agent 前要梳理流程。不是把现有制度全文塞进 prompt，而是把流程转成可执行规则、工具权限和验收条件。比如报销助手需要知道费用类型、票据要求、审批链、金额阈值和例外处理；招聘助手需要知道岗位要求、候选人隐私、面试阶段和拒信模板；运维助手需要知道变更窗口、回滚方案、审批人和告警级别。

流程不清时，Agent 会暴露组织混乱。一个部门说按 A 规则，另一个部门说按 B 规则；文档里写一种做法，实际执行又是另一种；系统字段叫法和业务人员叫法不一致。模型不是流程治理工具，它只能把混乱放大。真正要让 Agent 完成任务，先要把关键流程标准化。

组织流程还决定人工介入点。谁能批准高风险动作，谁能判断专业争议，谁负责处理失败任务，谁维护知识库，谁复盘事故。如果这些责任没有归属，Agent 遇到边界问题就会停在那里。生产 Agent 需要的不只是模型能力，还有明确的运营责任。

流程变化也要进入版本管理。业务规则今天改了，Agent 明天还按旧规则执行，就是事故。知识库文档、工具权限、任务模板、验收规则都应该有版本和发布时间。Agent 生成结论时，应使用当前有效版本，并能说明依据。对高风险业务，过期规则比没有规则更危险。

十七、不要让提示词承担全部责任

Agent 烂尾后，很多团队第一反应是改提示词：加一句“必须完成任务”，加一句“不要放弃”，加一句“失败后继续尝试”，加一句“最终必须验收”。这些提示词有时能改善表现，但不能解决结构问题。提示词能影响模型行为，不能提供缺失的状态、权限、工具语义和验收机制。

“必须完成任务”如果没有退出条件，会鼓励模型硬撑。资料不足时它可能编造，权限不足时它可能绕路，测试失败时它可能忽略。生产系统更需要“在满足验收条件时完成，在证据不足时停止并说明，在高风险动作前请求确认”。这比单纯要求坚持更可靠。

“失败后继续尝试”如果没有失败分类，会导致重复。网络超时可以重试，参数错误应该修参数，权限错误应该请求授权，业务冲突应该交给人，不可逆风险应该停止。提示词很难稳定完成这些判断，工具层应该返回明确错误类型，状态机应该决定下一步。

“最终必须验收”如果没有验收工具，也只是口号。模型不能自己证明测试通过，必须真的运行测试；不能自己证明引用正确，必须能定位来源；不能自己证明提交成功，必须拿到回执。验收是系统能力，不是语气要求。

好的提示词仍然重要。它负责让模型理解角色、目标、优先级和表达方式。但提示词应该站在系统设计之上，而不是替代系统设计。边界靠任务契约，状态靠持久化，工具靠接口设计，验收靠检查器，提示词负责把这些信息组织给模型使用。

十八、一个最小可行的防烂尾清单

做一个不容易烂尾的 Agent，不一定一开始就搭复杂平台。可以从最小清单开始。第一，每个任务进入执行前，都有目标、范围、交付物和验收方式。第二，每个任务都有状态记录，至少包含已完成、待处理、阻塞和证据。第三，每个工具都有清晰错误类型和可读返回。第四，每个高风险动作前都有确认。第五，每个完成声明都有外部证据。

第六，给任务设置预算。最大步骤数、最大耗时和最大重试次数能防止无意义循环。第七，失败时输出阻塞原因，而不是编造完成。第八，把失败样本回收进评测。第九，定期查看任务日志，找出最常见烂尾点。第十，把常见成功路径固化成 workflow，把不确定部分留给 Agent。

这个清单的重点，是把“智能”落到可执行结构里。Agent 不需要每一步都自由发挥。很多成熟能力应该变成固定流程，例如检索后重排、写作后查重、代码修改后测试、提交前预览、失败后分类。模型负责处理复杂判断，流程负责保证基本可靠。

当最小清单跑通后，再逐步增强。增加更好的规划器、更多工具、更细权限、更强评测、更丰富人机协同、更长任务恢复。不要反过来先堆工具和模型，再补状态和验收。那样演示会很快，生产会很痛。

参考资料

]]>https://localaihub.com/topic/16/ai-agent为什么容易烂尾-任务边界-状态-工具和验收RSS for NodeWed, 03 Jun 2026 18:50:37 GMTThu, 21 May 2026 21:10:47 GMT60