你如何看待 Agent 的发展趋势？

核心回答

我看好 Agent 在边界清楚、结果可验证的任务里，承担越来越完整的执行过程。结合已经公开的模型训练和工程实践，我主要关注三个方向：

1. 模型更擅长执行多步任务。 通过可执行任务和环境反馈训练工具选择、行动顺序与失败修正，而不只提高单次回答质量。
2. 系统更重视状态和恢复。 保存已完成步骤和必要结果，中断后能继续，并在关键操作上让人接管，减少重复执行和人工补救。
3. 评价更关注合格交付。 同时检查过程和最终结果，衡量完成率、人工修正量，以及包含重试和复核的一次任务总成本。

例如研究助手查完数据后生成 PDF 失败，真正有价值的是保留已有材料、修复转换问题并检查最终文件。这比只生成一段“任务已完成”的回复更接近用户需要的结果。

这些方向已有公开实现。我预计，代码维护、资料研究和数据处理等有反馈、有验收标准的任务，会更容易扩大自动化范围；具体范围仍取决于实际任务的质量和总成本。

这个判断有哪些依据？

第一，模型训练进一步面向行动过程。 Qwen3-Coder-Next 的技术报告把可执行任务、环境反馈和强化学习用于多步代码修改、工具使用及失败恢复。这说明提升 Agent 能力的路线已经超出静态问答训练。我的预测是，模型会逐步学会更合适的行动顺序，减少应用层为特定弱点编写的补救规则；这一结果仍取决于训练任务和实际环境是否匹配。

第二，运行系统越来越重视状态和恢复。 AgentScope 已提供状态保存、会话加载；Anthropic 的 Managed Agents 工程说明则把持久会话记录、运行循环和执行环境分离，使某个运行组件故障后能重新读取进展。这些是已经公开的实现。由此我更看好能持续推进任务的系统，同时也会随模型变化重新评估编排逻辑，避免旧补丁长期堆积。

第三，评估更重视同时检查过程与最终结果。 国内的 AgentScope 评测模块区分任务、指标、执行轨迹和最终输出；Anthropic 的评估文章进一步强调，Agent 声称订票成功，与数据库里确实存在订单是两件事。我的判断是，产品竞争会更重视稳定交付和人工修正成本，单次演示的说服力会下降。

放到一项研搜任务里，会怎样体现？

以“从数据库查询药品信息，并生成 PDF”为例，任务需要查表、查询数据、整理 Markdown，再生成文件。假设数据已查到而 PDF 转换失败，有用的下一步是保留查询结果和 Markdown，修正转换问题后继续；如果进程中断，则需要从持久记录找回进展。

这里要检查的是文件能否打开、内容是否对应查询结果、必要字段是否齐全。保存了对话文本，并不自动等于完成了业务恢复：还要知道哪一步已经执行、哪些外部状态已经改变。重复查询也可能读到新数据，因此恢复时需要明确沿用哪次查询结果。设计验收时，我还会把查询快照、Markdown 版本与本次生成的文件关联起来，避免把上一次留下的可打开文件，误当成本次任务已经完成。模型选择了正确的下一步，与应用保存了正确的状态和产物，是两件需要分别验证的事。

这个例子反映了我的技术取舍：固定转换和检查步骤可以用程序完成，调查方向需要随材料变化时再交给 Agent。多 Agent、MCP 和 Skills 都可服务于具体分工与复用，是否采用要看它们对交付质量、成本和维护的实际影响。

怎样检验这个判断？

我会用同一组任务，对比人工处理、固定工作流和 Agent，并把失败恢复也算进去：

• 任务完成情况： 结果有依据、报告不漏项、文件可用，多次运行能否稳定达到标准。
• 人工接管量： 人需要补多少资料、修正多少错误、重新操作多少步骤。
• 一次合格交付的总成本： 模型和工具费用、失败重试、等待时间，以及人工复核与返工成本。

比较时还要固定任务、数据与初始环境，对同一任务重复运行。一次演示能成功，只证明找到过一条可行路径；五次运行只有一次交付合格，与五次都能交付，是不同的使用体验。评测时要让每次执行从各自的初始状态开始，避免沿用前一次的文件或已完成动作，产生虚假的稳定性。

成本也要按合格交付核算：同一批任务全部执行的模型与工具总消耗，包含最终失败的任务和内部重试，再除以合格交付的任务数；内部重试不增加交付次数。没有合格交付时，报告零交付和总消耗，并另报人工复核、返工与等待时间。一个方案单次调用更便宜，却需要更多轮尝试或人工修正，整体未必更划算。人工时间与调用费用先分别记录，需要合成成本时再说明工时换算口径。

如果多次模型调用只带来更长的报告，却增加了复核和返工，就需要缩小自动化范围；范围较窄但能稳定节约人工的任务，也有明确价值。

追问

强化学习还会是一条重要路线吗？

我认为会，尤其适用于代码执行、测试等能提供可检查反馈的任务；Qwen3-Coder-Next 已展示这条路线。不过奖励设计可能偏离真实需求，例如为了通过检查而走捷径，所以还要看独立测试和新任务上的表现。训练也无法替代业务系统的权限校验，或补出用户从未提供的订单编号。

模型越来越强，是不是就不需要工程编排了？

要分别看模型补丁和业务责任。为弥补某个模型弱点增加的提示、重试或上下文处理，可以随模型升级重新评估；但应用仍要管理凭证、执行外部动作、保存进度、验证产物，并处理结果未知时的重复执行问题。例如模型更会修正 PDF 转换参数，不会自动让内存中的查询结果在进程退出后继续存在。更合理的方向是减少失去作用的补丁，同时保留任务实际需要的运行保障。

哪些 Agent 应用更难保持竞争力？

我认为，缺少特定业务数据、执行能力和持续效率收益的应用更容易失去差异。更值得积累的是任务规则、可靠工具、评估样例和真实失败记录：这些决定用户能否少返工、持续使用。是否采用某个新协议，本身不能证明产品价值。

它到底能取代哪些工作？

我会先按工作环节判断。资料检索、格式整理、草稿生成和结果可核对的重复操作，更容易被部分自动化。目标不清时的沟通、结论取舍，以及后果难以撤销的决定，仍需要明确的人承担判断。查药品资料并生成报告，也不等于能够独立作出医疗决策。

什么证据会让你修正观点？

如果更强模型配合简单工具循环，就能稳定达到同样质量，我会减少专门编排；如果人工复核、失败补救和等待成本长期高于节省的成本，我会缩小应用范围。架构和自动化程度都随任务结果调整。

对应教程

参考资料