专栏AI Agent 开发03先记住一个结论Agent 并不是 2023 年突然被“发明”出来的。真正变化的是大模型开始逐渐具备执行多步任务所需要的能力开发者终于能把“让模型决定下一步”做得没那么脆弱。一、先从一个很简单的问题开始会回答为什么还不够假设用户说“帮我订明天去上海的高铁票。”普通聊天模型当然可以回答你可以打开购票软件选择日期、车次再填写乘车人信息。这个回答没问题但它只是“告诉你怎么做”。如果我们真的想让 Agent 去完成任务事情马上变复杂它得先确认出发城市和日期再查车次看到结果后选合适的班次必要时追问用户最后还要在真正提交订单前请求确认。这时候你会发现Agent 的难点从来不是“模型能不能说出一段像样的话”而是下面这条链路能不能稳定跑起来听懂任务 → 决定下一步 → 产生机器可读动作 → 调用外部能力 → 读取结果 → 再决定下一步。图 1 会聊天和能执行任务之间还隔着一整条“程序可执行”的链路二、为什么以前这条链路特别容易断早期语言模型更擅长“接着写文本”。你可以在 Prompt 里告诉它“如果需要查天气就输出 WEATHER”但模型可能返回“好的我建议先查询 WEATHER”也可能顺手多解释两句。对人来说都看得懂对程序来说却很麻烦。reply model(如果需要天气请只输出 WEATHER) if reply WEATHER: weather get_weather() else: # 现实里 reply 往往不是你想象的那么规整 ...这类写法的问题不是模型“笨”而是模型输出和程序控制之间没有稳定的数据契约。只要格式稍微偏一点后面的逻辑就可能走错。所以理解 Agent 的一个关键视角是模型能力不是只看“回答质量”还要看它能不能稳定地参与软件的控制流程。三、真正把 Agent 往前推的是六类能力逐渐成熟下面这六项不是严格的历史分界线也不是说某一年以前完全没有、某一年以后突然百分之百可靠。更准确的理解是它们在近几年逐渐变得更实用组合起来以后Agent 的工程成本明显下降。图 2 Agent 的可用性来自多种能力叠加而不是某一个框架突然出现1. 指令遵循先把“你到底要我做什么”听明白Agent 每一步都依赖模型理解目标和约束。比如“查到价格后先别下单超过 500 元要问我”这里同时包含任务目标和行为边界。指令微调和基于人类偏好的训练让模型比早期纯文本补全模型更擅长按要求完成任务。对 Agent 来说这相当于先解决“别一上来就跑偏”。2. 结构化输出让模型结果能直接进入代码程序真正喜欢的不是一段自然语言而是明确的数据结构。比如分类结果最好是 {category: 退款}而不是“我认为这应该属于退款类问题”。JSON Mode 能帮助模型输出合法 JSON更严格的 Structured Outputs / Schema 约束则进一步让输出匹配开发者给定的结构。需要注意格式可靠不等于内容一定正确字段里的值仍然可能判断错。{ action: search_train, from: 武汉, to: 上海, date: 2026-08-14 }3. 工具调用模型终于能明确表达“下一步想调用什么”这是 Agent 里最容易让人真正“看懂”的变化。开发者把可用工具及参数说明提供给模型模型不直接执行函数而是返回类似“我要调用 get_weather参数 city北京”的结构化动作。图 3 Tool Calling 中模型负责选择动作Runtime 负责校验和真正执行这个边界非常重要模型不是拿着你的 API Key 自己在网络上乱跑。真正的程序仍然要做参数校验、权限判断、超时处理再决定是否执行。4. 更长的上下文多走几步以后不至于马上忘掉前面Agent 做多步任务时每一步都要参考前面的用户要求、工具结果和中间状态。上下文窗口扩大后能保留的信息更多多步任务更容易保持连续。但这里不要得出“上下文越长越好”的结论。塞进去的内容越多Token、延迟和干扰也会增加。后面的 Context Engineering 正是解决“该放什么、不该放什么”。5. 多模态Agent 不再只能读文字当模型可以理解图片后Agent 能处理的任务立刻扩展了。例如用户上传报错截图客服 Agent 可以先读图测试 Agent 可以检查页面截图文档 Agent 也能处理扫描件中的视觉信息。多模态解决的是“观察范围”问题Agent 想根据环境做决定首先得能看到环境提供的信息。6. 推理能力复杂任务前能做更充分的判断近年的推理模型更擅长处理需要多步分析的数学、代码和规划类任务。对 Agent 来说这会直接影响“下一步选什么”的质量。不过不要把它理解成“模型会展示完整思维过程”。实际产品里模型的内部推理并不等于应该原样暴露给用户工程上真正关心的是最终决策、工具调用和可验证的执行结果。四、把六项能力放回一个真实任务里还是刚才的“订明天去上海的高铁票”。如果把它拆开你就能看到这些能力不是概念而是每一步都真的有用任务里的动作依赖的能力为什么需要理解“明天”“去上海”“先别下单”指令遵循先理解目标和约束决定先查车次推理 Tool Calling运行时决定下一步生成出发地/目的地/日期参数结构化输出程序才能稳定执行记住用户之前说过预算 500 元上下文后续决策要参考前情用户发来身份证截图多模态读取文本之外的信息查完车次后比较时间和价格推理根据 Observation 继续判断这也是为什么“Agent 突然流行”不能只归因于某一个框架。LangGraph、Agents SDK、AutoGen 等框架解决的是 Runtime 和工程抽象它们之所以今天更有用是因为底层模型已经更适合参与这些控制流程。五、那是不是模型变强以后Agent 就很容易上线了还不是。模型能力解决的是“这件事开始能做”生产系统还要解决“它能不能稳定、便宜、安全地做”。• 一步选错工具后面的步骤可能继续在错误结果上往下走所以需要校验、重试和必要时重新规划。• 每多走一步通常就多一次模型或工具调用所以必须设置最大步数、Token Budget 和成本上限。• 工具参数即使格式合法值也可能不合理例如城市为空、金额越界因此 Runtime 仍要做业务校验。• 删除文件、发邮件、支付等有副作用的动作不能因为模型“决定了”就直接执行需要权限和人工审批。• 同一个任务的执行轨迹可能不同所以测试不仅要看最终答案还要看工具是否选对、任务是否真的完成。可以把它理解成模型能力让 Agent“能跑起来”而 Runtime、权限、评测、Tracing、HITL 等工程能力决定它“能不能上线”。六、这一篇真正要记住什么• Agent 的思想并不新近几年真正变化的是基础模型更适合参与多步软件控制。• 指令遵循、结构化输出、工具调用、上下文、多模态和推理能力是理解这种变化的六个很好用的观察角度。• Tool Calling 不是模型亲自执行 API而是模型产生动作建议Runtime 校验并执行。• 结构化输出解决“格式可消费”不代表业务内容百分之百正确。• 模型更强只解决可行性生产 Agent 仍然需要步数限制、权限、错误处理、评测和可观测性。七、下一篇下一篇 04《一个真正的 Agent 内部到底发生了什么》不再继续讲历史和概念而是把一次 Agent Run 拆开Context 是怎么组装的模型怎样产生 ActionTool 怎么执行Observation 怎么回填以及为什么这个循环会一直跑到任务完成或触发停止条件。