如果你最近持续关注 AI 产品动态应该能明显感受到一股转向OpenAI 在把重心从“聊天框”挪到“能动手干活的 Agent”各家大厂也在从“生成内容”转向“执行任务”。OpenAI 产品团队在多个场合把这一轮变化概括为AI 第三时代。这个词听起来像媒体标题但拆开之后它其实指向一个非常具体的技术迁移——AI 不再只是生成一段文本、一段代码而是开始连续地调用工具、读取数据、做出决策甚至独立完成一条业务链路。这篇文章想做一个更务实的讨论AI 第三时代为什么不是一句口号它的技术基础、产品形态和工程挑战到底是什么以及一个普通后端工程师或 AI 应用开发者能不能在这个阶段找到真正能落地的切入点。读完这篇文章你会得到一个判断框架、一套可运行的 API 示例以及一批可以避开的真实工程坑。1. 这篇文章真正要解决的问题1.1 信息过载之下的判断困境现在每天都有新的 AI 概念出现Agent、多智能体、工作流、MCP、RAG、Function Calling、AI 编程、模型评测。多数文章要么在介绍概念要么在展示演示视频。但演示视频和可用产品之间存在一条巨大的鸿沟。你真正需要回答的问题只有一个当一个 AI 产品号称进入“第三时代”时它到底改变了哪一层是模型能力变了软件架构变了还是只是交互入口变了这个问题如果不搞清楚很容易做出错误决策。比如看到别人接了一个 Agent 框架自己也跟着接结果发现模型经常乱调工具、上下文越来越长、线上服务还出现权限风险。这些问题的根源往往不在模型能力而在你对“AI 第三时代”的底层逻辑理解得不够。1.2 开发者最需要补的能力传统开发者的能力模型里写代码、查数据库、调接口是基本盘。但到了 AI 第三时代你需要额外掌握四件事把业务能力改造成模型可调用的工具并做清晰描述。设计 Agent 的多步执行逻辑而不是简单的问答循环。评估 Agent 的任务成功率、延迟和成本而不是只看回答好不好。处理权限边界、异常恢复和日志追踪保证 Agent 在线上不惹祸。这些能力不会因为模型变强而自动消失反而会越来越重要。因为模型越强它可以“操作”的范围就越大出问题的后果也越严重。1.3 读完本文你可以带走的方法我不会只讲概念。本文会先给你一个阶段划分框架然后从一个具体的库存查询场景出发用 OpenAI API 搭出最小可用 Agent再给出评测脚本、常见问题排查思路以及一套适合团队落地的工程建议。你不需要是 AI 研究员只要会 Python、理解 API 调用就能跟下来。2. 什么是“AI 第三时代”分界不是模型而是分工2.1 第一时代AI 是预测器回顾 AI 进入软件行业的第一个阶段核心词是“预测”。传统机器学习、深度学习模型被嵌在软件系统内部承担特定任务广告点击率预测、商品推荐、垃圾邮件过滤、人脸识别、信用评分。第一时代里AI 不直接面对用户也不生成内容。它像一个内部组件输入结构化数据输出一个概率或标签配合规则引擎完成业务逻辑。这个阶段的开发模式是“训练模型 上线服务”工程重点在数据质量、特征工程、模型推理性能。第一时代的局限性很明显模型的能力边界窄只能做已经定义好的预测任务。你没法让一个推荐模型帮你写方案也没法让一个分类模型自行完成多步骤业务操作。2.2 第二时代AI 是生成器第二时代的标志是大语言模型和扩散模型。GPT、Claude、文心一言、Stable Diffusion 这类模型可以生成文本、代码、图像和音频能力边界从“判断”扩展到了“创造”。这个阶段的产品形态最典型的是各类对话助手和 Copilot。用户给出描述模型生成回答或代码然后由人来审查、修改、接受。人的角色是“最终决策者”模型是“内容提案者”。第二时代对软件工程的影响很大开发效率提升了写代码的姿势变了很多重复劳动被自动化解掉。但你也会发现一个问题——生成内容不等于完成任务。模型可以给你一段 SQL但不会帮你把 SQL 执行完可以给你一段 Python 代码但不会主动帮你跑测试、修 bug、部署上线。2.3 第三时代AI 是执行者第三时代的形态是把“生成”升级成“执行”。AI 不再只是一个输出文本的端点而是一个具备感知、决策、行动、反馈修正的体统。你可以让它完成这样的任务看到用户诉求后调用库存接口获取数据。根据数据判断是否需要创建补货单。调用下单接口生成补货单。执行完以后把结果以自然语言汇报给用户。整个过程跨多个工具包含多轮决策模型每一步都在“行动”。这正是 OpenAPI 产品团队所说的第三时代核心从“会聊天”变成“会干活”。2.4 三个阶段不是替代而是叠加需要澄清一点第三时代不会消灭前两个阶段。预测、生成、执行是三种能力它们会叠加在同一个系统里。一个典型应用仍然需要推荐模型来预测用户偏好需要大模型来生成话术但同时还需要一套 Agent 逻辑把推荐结果、话术生成、订单操作串起来。理解这一点很有价值。它意味着你不需要推翻现有系统而是可以在已有 AI 能力之上增加一层“执行编排”的能力。第三时代的真正增量就在这层编排能力上。3. 从对话到行动第三时代的六大技术信号3.1 工具调用成为核心能力对话时代里模型只接受文本并输出文本。到了第三时代模型需要能够“调用函数”。OpenAI 在 Chat Completions API 中引入了 tools 参数模型可以在对话过程中输出结构化的 tool_calls然后由你的代码执行真实函数再把结果回传给模型继续推理。API 层面看起来只是多了一个参数但它改变了整个应用架构。模型从“告诉你答案”变成“请求你执行某个操作”这是 Agent 行为的起点。3.2 上下文工程比提示词工程更关键提示词工程解决的是“怎么让模型说好”上下文工程解决的是“怎么让模型在正确的信息状态里做决策”。第三时代模型要处理多轮工具调用所以上下文需要包含系统指令、用户目标、历史轨迹、工具返回结果、中间推理状态。这意味着你要认真设计上下文的结构。哪些信息必须放进去哪些可以放在外部数据库哪些历史需要截断都会影响 Agent 的质量和成本。3.3 记忆被外部化对话模型自带有限的上下文窗口但 Agent 执行复杂任务时记忆不能只躺在模型上下文里。第三时代会把记忆拆成三层短期记忆当前任务的执行轨迹。长期记忆用户偏好、历史订单、业务规则等存放在数据库或向量库中。外部状态订单状态、库存数量、任务进度存业务系统里。模型只持有与当前决策相关的部分其他部分通过检索工具按需获取。这样做既节省 token又避免模型上下文被无关信息污染。3.4 多步任务需要状态机与编排没有工具调用时模型是一问一答。有了工具调用后模型可能有 3 到 10 步的操作序列这些步骤之间还可能有分支和条件判断。你不能只写一个简单的请求-响应循环就要引入轻量级状态机甚至编排框架。编排层的工作包括判断步骤是否结束、记录每步调用的参数和结果、设置最大步数、处理异常分支、决定何时需要人工介入。3.5 评估体系从“回答质量”走向“任务成功率”传统 Chatbot 评估看语句通顺度、内容准确性。Agent 评估必须看另一套指标任务完成率、工具调用成功率、平均步数、平均延迟、单任务成本、异常回滚率。回答再漂亮任务没执行成功系统就是不可用的。这就把 AI 从“写作文”的评价体系拉回到“做软件”的评价体系。对团队来说这是一个特别重要的思维转换。3.6 基础设施开始为 Agent 优化OpenAI 在自研芯片、算力基础设施上的投入以及其他大厂跟进部署大规模 Agent 推理集群本质上都是在为第三时代铺路。Agent 任务的推理次数远高于单轮对话一个任务可能消耗几十次模型调用。没有成本更低的推理基础设施Agent 很难大面积商业化。从开发者社区的信息也能看到OpenAI 的工具链正在从“对话界面”扩展到命令行工具和编程代理。这些信号都指向同一个方向让 AI 不只是生成文本而是低成本地执行大量任务。4. 第三时代的产品形态从对话框到工作流4.1 对话框只是入口很多人以为 Agent 就是把 Chatbot 做聪明一点。实际上第三时代的产品形态会从“对话框”演变成“入口 工作流 反馈”的结构。对话框成为用户发起任务的入口但任务在后台由多条工作流处理。用户说“帮我查一下 A1001 的库存并按安全库存生成补货单”。传统 Chatbot 只能回复一段文字说明它没有权限、无法操作。第三时代的应用会实际调用库存接口查到实时数据再判断是否缺货随后触发补货单审批流。用户最后收到的不是一个“建议”而是一个“已完成的动作”或者“等待确认的审批事项”。4.2 一个典型的第三时代应用长什么样这里用一个客服工单处理场景来说明。假设用户提交了一个工单“我买的键盘无法连接电脑想退换货。”第一步Agent 调用客户信息接口获取订单详情。第二步Agent 根据售后规则判断该订单是否在退换货期内。第三步Agent 创建退换货工单并在 CRM 系统里标记状态。第四步Agent 生成给用户的回复说明退换货流程和物流地址。从用户视角他只是在对话框里说了一句话但这背后发生了四次工具调用、至少三轮模型推理。这就是第三时代产品与传统 Chatbot 的本质区别。4.3 产品经理和开发者的视角变化对产品经理来说功能定义从“界面上的按钮”变成“Agent 能执行的任务”对开发者来说研发对象从页面、接口变成工具集、权限策略、回滚机制和观测系统。这两类角色都需要重新理解“系统边界”。过去我们习惯把功能拆成多个页面和 API 让用户手动点。现在Agent 会把本来由人点击的操作串联起来。这要求业务逻辑必须足够“语义化”能够被模型理解并翻译成工具调用。5. 实操用 OpenAI API 快速搭建一个最小 Agent5.1 环境准备与前置条件我们的目标不是做一个复杂框架而是演示 Agent 的最小闭环模型理解用户请求调用工具拿到结果最终给出回答。环境要求很简单Python 3.9 以上。安装 openai 官方 Python SDK 和 python-dotenv。一个可用的 OpenAI API Key模型选择以账号实际可用为准本文示例使用常见的 gpt-4o-mini。建议使用虚拟环境隔离依赖python -m venv .venv source .venv/bin/activate pip install openai python-dotenv在项目根目录创建.env文件OPENAI_API_KEYsk-your-key加载环境变量import os from dotenv import load_dotenv load_dotenv() from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY))这里真正容易踩坑的地方是不要把 API Key 硬编码在代码里也不要把.env文件提交到 Git 仓库。后面接 CI/CD 时也建议通过密钥管理服务注入环境变量。5.2 第一版让模型学会调用工具我们实现一个最简单的库存查询工具。为了演示使用内存字典代替真实数据库。import json from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) inventory { A1001: {name: 无线路由器, stock: 23}, B2002: {name: 机械键盘, stock: 0}, } def query_inventory(sku: str) - str: item inventory.get(sku) if item is None: return json.dumps({error: SKU 不存在}) return json.dumps({sku: sku, name: item[name], stock: item[stock]}) TOOLS [ { type: function, function: { name: query_inventory, description: 根据 SKU 查询商品库存返回 JSON 字符串, parameters: { type: object, properties: { sku: { type: string, description: 商品 SKU 编号例如 A1001 } }, required: [sku] } } } ]代码里的关键点有三个工具描述要清楚模型根据描述决定是否调用。描述模糊模型就会乱猜。参数定义要严格required 字段不能漏。工具返回值必须是序列化友好的文本模型拿到后会继续推理。5.3 第二版多轮工具调用循环真正的 Agent 需要支持多轮模型可能第一次只请求查库存拿到结果后还需要继续判断。因此代码必须循环处理 model 返回的 tool_calls并把结果回传给模型。def run_agent(user_input: str, max_steps: int 5): messages [ {role: system, content: 你是一个库存查询助手只能使用 query_inventory 工具不能编造库存数据。}, {role: user, content: user_input} ] for step in range(max_steps): response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto, ) message response.choices[0].message # 模型不再调用工具说明任务已结束 if not message.tool_calls: return message.content # 保留模型本轮的消息及其 tool_calls messages.append({ role: message.role, content: message.content, tool_calls: [tc.model_dump() for tc in message.tool_calls] }) # 遍历模型请求的工具调用 for tool_call in message.tool_calls: if tool_call.function.name query_inventory: args json.loads(tool_call.function.arguments) tool_result query_inventory(args[sku]) else: tool_result json.dumps({error: 未知工具}) messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result }) return 达到最大步数未完成任务 if __name__ __main__: print(run_agent(A1001 还剩多少库存)) print(run_agent(B2002 库存不足怎么办))这版代码有几个值得解释的细节关闭工具调用的条件不是“某个关键词”而是 message.tool_calls 为空。每次工具结果都要和 tool_call_id 对应否则模型无法关联结果。设置 max_steps 非常重要防止模型陷入死循环。tc.model_dump()是为了把 tool_calls 序列化成普通字典不同 SDK 版本可能略有差异但思路一致。如果模型不返回 tool_calls极大可能是因为 prompt 里没有限制它必须用工具。你可以把 system prompt 改成“你必须调用 query_inventory 工具来回答库存问题”或者把 tool_choice 从auto改成required来测试。5.4 运行结果与效果验证运行上面代码最直接的验证方式是打印中间步骤。建议先写一个带日志的版本if __name__ __main__: result run_agent(A1001 还剩多少库存) print(最终回答:, result)预期输出是模型基于工具结果生成的自然语言例如A1001 无线路由器当前库存为 23 件。这里要额外提醒模型生成的自然语言可能会变但工具返回的真实数据是确定的。你判断成功与否不应该看模型说了什么而应该看它是否真的调用了工具、调用的参数是否正确、结果是否被正确引用。建议在日志中打印每一次 tool_call 的名称、参数和 tool 返回结果。5.5 为工具调用加上安全边界上面示例中模型只要返回一个函数名代码就会执行。这在实际项目中很危险。真实系统里你还需要做权限校验、参数白名单、操作类型限制。下面是一个安全调用示例TOOL_MAP { query_inventory: query_inventory, } ALLOWED_TOOLS {query_inventory} def call_tool_safely(tool_name: str, args: dict): if tool_name not in ALLOWED_TOOLS: raise PermissionError(f工具 {tool_name} 未在白名单内) func TOOL_MAP[tool_name] return func(**args)把 “模型请求调用工具” 和 “代码真实执行工具” 之间加一道闸是最基本的安全边界。6. 如何评估一个 Agent不能只看演示视频6.1 评估指标的四个维度Agent 上线前你至少要看这四个维度的指标维度指标示例说明成功率任务完成率在所有测试场景中完成预期业务动作的比例稳定性工具调用成功率模型是否输出了可解析的工具参数效率平均步数、平均延迟完成任务消耗多少步每步延迟多少成本单任务 token 消耗输入 token 与输出 token 总量换算成成本只有成功率不够。一个 Agent 如果平均跑 8 步延迟 15 秒费用 0.8 美元即便成功率很高也不一定能商业化。6.2 一个简单的评估脚本下面是一个面向测试用例的轻量评估骨架你可以把它扩展到自己的数据集import time import statistics def evaluate_agent(run_agent, test_cases): results [] success_count 0 for case in test_cases: start_time time.time() try: output run_agent(case[input]) success bool(output) and case[expect_success] except Exception as exc: output str(exc) success False latency round(time.time() - start_time, 2) success_count 1 if success else 0 results.append({ input: case[input], success: success, latency: latency, output_preview: output[:80] }) success_rate success_count / len(test_cases) avg_latency statistics.mean([item[latency] for item in results]) return { success_rate: success_rate, avg_latency: avg_latency, results: results, } test_cases [ {input: A1001 还有多少库存, expect_success: True}, {input: 查询 B2002 的库存情况, expect_success: True}, {input: 讲述一个程序员的故事, expect_success: False}, ] if __name__ __main__: report evaluate_agent(run_agent, test_cases) print(f成功率: {report[success_rate]}) print(f平均延迟: {report[avg_latency]}s)这段脚本里的expect_success表示该输入是否应该被 Agent 接受。比如“讲述一个程序员的故事”不应该触发库存查询如果模型也调用了工具说明意图过滤有问题。成本统计需要你在 run_agent 里把每次 response.usage 的 token 数累加再按实际模型单价计算这里不再展开。6.3 线上灰度与回滚Agent 很难一次性做到高成功率所以上线策略比传统功能更保守。建议按“影子模式 - 人工审批模式 - 自动执行模式”三步走。影子模式Agent 执行所有动作但不真正写库只记录日志。人工审批模式Agent 给出操作建议由人点击确认后执行。自动执行模式只在成功率稳定、风险可控的任务上放开自动执行。回滚策略上除了代码版本回滚还要准备“操作补偿”。比如 Agent 已经创建了订单你必须有取消订单的工具否则无法恢复错误状态。7. 常见问题与排查思路7.1 Agent 常见问题一览问题现象可能原因排查方式解决方案模型一直不调用工具tools 参数未正确传递或 system prompt 未限定工具打印 response 的 tool_calls 字段检查工具定义格式把 tool_choice 设为 required 测试工具参数解析失败模型返回的 arguments 为空或不是合法 JSON捕获 JSONDecodeError 并打印原始参数简化参数结构增加重试机制用枚举值限制取值Agent 执行了不该执行的操作工具权限过大被 prompt 注入诱导检查日志中的 tool_call 序列设置工具白名单限制危险工具重要操作加人工确认上下文越来越长费用飙升多轮工具结果全部塞进历史消息统计每次请求的 messages 大小和 token 消耗压缩工具结果只保留最近几轮外部化记忆Agent 看似成功但结果错误评测只看是否完成动作未校验业务正确性对比 tool 返回值和预期结果增加业务断言对工具返回值做二次校验7.2 模型一直不调用工具这是一个新手最容易遇到的问题。先检查两点tools 参数是否真的传入到了 chat.completions.create 中。返回的 message.tool_calls 是否为 None。如果 tool_calls 为空说明模型认为不需要调用。你可以把 system prompt 改成“你只能通过 query_inventory 工具获取库存信息不得猜测。” 或者直接用 tool_choicerequired 强制模型调用工具确认工具链路本身通不通。7.3 上下文太长与成本不可控Agent 每一步都会把历史消息传给模型工具结果也可能很大。解决思路有三条截断历史只需要保留最近两轮 tool 调用信息。压缩工具结果库存接口如果返回 100 条记录模型未必都需要可以只返回汇总。设计外部记忆长期信息存数据库或向量库Agent 需要时通过检索工具获取。建议在架构设计阶段就把“外部记忆”作为第一选择不要把模型上下文当数据库用。8. 最佳实践与工程建议8.1 给 Agent 最小权限Agent 默认不应该拥有权限。你要像对待一个刚入职的新员工一样对待它只给必要工具只给必要数据范围只允许在必要时间段执行。生产环境里把“查询”和“写操作”分开设计写操作全部走审批。8.2 让 Agent 的每一步可观测不要只记录最终结果。最好的做法是输出一个结构化的 trace 日志{ agent_run_id: uuid-123, step: 2, tool: query_inventory, args: {sku: A1001}, result: {\sku\:\A1001\,\stock\:23}, latency_ms: 320, tokens: {prompt: 1200, completion: 80} }这些日志可以用于问题排查、成本核算和评测集构建。第三时代最值钱的数据资产就是这些 Agent 执行轨迹。8.3 控制成本与延迟控制成本最有效的方式是限制最大步数、限制单次工具结果大小、使用小模型处理简单分支、用规则引擎前置过滤掉明显不需要 Agent 的任务。延迟优化则需要考虑模型选择、请求并发和工具接口耗时。8.4 从单任务场景开始不要第一个项目就做一个“全知全能”的智能体。先选一个边界清晰、步骤少、风险低的任务让 Agent 跑通再逐步扩展。库存查询、订单进度查询、报销单初审都是比较好的起步场景。8.5 团队协作要重新分工Agent 项目会改变团队协作方式。Prompt 工程不再只是提示词写手的事它与工具设计、权限策略、评测数据强耦合。建议团队里至少有一个人专门负责“工具体验”工具描述是否清晰、参数是否简洁、返回结果是否容易被模型理解。工具设计得好不好决定了 Agent 能力的上限。9. 写在最后先让 Agent 做一件小事AI 第三时代不是一个遥不可及的概念。你不需要等到模型更强、框架更成熟才动手而是可以用一个库存查询工具把“模型生成内容”和“模型执行操作”之间的链路亲手打通。如果你的团队正在决定要不要上 Agent我的建议是不要先搭平台不要先画宏大蓝图。选一个三步以内就能完成的任务让 Agent 连续稳定地执行 100 次。在这个过程里你会遇到参数解析失败、工具权限失控、上下文膨胀、成本失控等各种问题。这些问题不会因为换一个更强的模型而消失它们是第三时代应用开发的“规定动作”。先让 Agent 做一件小事这句话听起来很平常但确实是你进入 AI 第三时代最有效的启动方式。
AI第三时代：从生成内容到执行任务，Agent应用开发实战指南
如果你最近持续关注 AI 产品动态应该能明显感受到一股转向OpenAI 在把重心从“聊天框”挪到“能动手干活的 Agent”各家大厂也在从“生成内容”转向“执行任务”。OpenAI 产品团队在多个场合把这一轮变化概括为AI 第三时代。这个词听起来像媒体标题但拆开之后它其实指向一个非常具体的技术迁移——AI 不再只是生成一段文本、一段代码而是开始连续地调用工具、读取数据、做出决策甚至独立完成一条业务链路。这篇文章想做一个更务实的讨论AI 第三时代为什么不是一句口号它的技术基础、产品形态和工程挑战到底是什么以及一个普通后端工程师或 AI 应用开发者能不能在这个阶段找到真正能落地的切入点。读完这篇文章你会得到一个判断框架、一套可运行的 API 示例以及一批可以避开的真实工程坑。1. 这篇文章真正要解决的问题1.1 信息过载之下的判断困境现在每天都有新的 AI 概念出现Agent、多智能体、工作流、MCP、RAG、Function Calling、AI 编程、模型评测。多数文章要么在介绍概念要么在展示演示视频。但演示视频和可用产品之间存在一条巨大的鸿沟。你真正需要回答的问题只有一个当一个 AI 产品号称进入“第三时代”时它到底改变了哪一层是模型能力变了软件架构变了还是只是交互入口变了这个问题如果不搞清楚很容易做出错误决策。比如看到别人接了一个 Agent 框架自己也跟着接结果发现模型经常乱调工具、上下文越来越长、线上服务还出现权限风险。这些问题的根源往往不在模型能力而在你对“AI 第三时代”的底层逻辑理解得不够。1.2 开发者最需要补的能力传统开发者的能力模型里写代码、查数据库、调接口是基本盘。但到了 AI 第三时代你需要额外掌握四件事把业务能力改造成模型可调用的工具并做清晰描述。设计 Agent 的多步执行逻辑而不是简单的问答循环。评估 Agent 的任务成功率、延迟和成本而不是只看回答好不好。处理权限边界、异常恢复和日志追踪保证 Agent 在线上不惹祸。这些能力不会因为模型变强而自动消失反而会越来越重要。因为模型越强它可以“操作”的范围就越大出问题的后果也越严重。1.3 读完本文你可以带走的方法我不会只讲概念。本文会先给你一个阶段划分框架然后从一个具体的库存查询场景出发用 OpenAI API 搭出最小可用 Agent再给出评测脚本、常见问题排查思路以及一套适合团队落地的工程建议。你不需要是 AI 研究员只要会 Python、理解 API 调用就能跟下来。2. 什么是“AI 第三时代”分界不是模型而是分工2.1 第一时代AI 是预测器回顾 AI 进入软件行业的第一个阶段核心词是“预测”。传统机器学习、深度学习模型被嵌在软件系统内部承担特定任务广告点击率预测、商品推荐、垃圾邮件过滤、人脸识别、信用评分。第一时代里AI 不直接面对用户也不生成内容。它像一个内部组件输入结构化数据输出一个概率或标签配合规则引擎完成业务逻辑。这个阶段的开发模式是“训练模型 上线服务”工程重点在数据质量、特征工程、模型推理性能。第一时代的局限性很明显模型的能力边界窄只能做已经定义好的预测任务。你没法让一个推荐模型帮你写方案也没法让一个分类模型自行完成多步骤业务操作。2.2 第二时代AI 是生成器第二时代的标志是大语言模型和扩散模型。GPT、Claude、文心一言、Stable Diffusion 这类模型可以生成文本、代码、图像和音频能力边界从“判断”扩展到了“创造”。这个阶段的产品形态最典型的是各类对话助手和 Copilot。用户给出描述模型生成回答或代码然后由人来审查、修改、接受。人的角色是“最终决策者”模型是“内容提案者”。第二时代对软件工程的影响很大开发效率提升了写代码的姿势变了很多重复劳动被自动化解掉。但你也会发现一个问题——生成内容不等于完成任务。模型可以给你一段 SQL但不会帮你把 SQL 执行完可以给你一段 Python 代码但不会主动帮你跑测试、修 bug、部署上线。2.3 第三时代AI 是执行者第三时代的形态是把“生成”升级成“执行”。AI 不再只是一个输出文本的端点而是一个具备感知、决策、行动、反馈修正的体统。你可以让它完成这样的任务看到用户诉求后调用库存接口获取数据。根据数据判断是否需要创建补货单。调用下单接口生成补货单。执行完以后把结果以自然语言汇报给用户。整个过程跨多个工具包含多轮决策模型每一步都在“行动”。这正是 OpenAPI 产品团队所说的第三时代核心从“会聊天”变成“会干活”。2.4 三个阶段不是替代而是叠加需要澄清一点第三时代不会消灭前两个阶段。预测、生成、执行是三种能力它们会叠加在同一个系统里。一个典型应用仍然需要推荐模型来预测用户偏好需要大模型来生成话术但同时还需要一套 Agent 逻辑把推荐结果、话术生成、订单操作串起来。理解这一点很有价值。它意味着你不需要推翻现有系统而是可以在已有 AI 能力之上增加一层“执行编排”的能力。第三时代的真正增量就在这层编排能力上。3. 从对话到行动第三时代的六大技术信号3.1 工具调用成为核心能力对话时代里模型只接受文本并输出文本。到了第三时代模型需要能够“调用函数”。OpenAI 在 Chat Completions API 中引入了 tools 参数模型可以在对话过程中输出结构化的 tool_calls然后由你的代码执行真实函数再把结果回传给模型继续推理。API 层面看起来只是多了一个参数但它改变了整个应用架构。模型从“告诉你答案”变成“请求你执行某个操作”这是 Agent 行为的起点。3.2 上下文工程比提示词工程更关键提示词工程解决的是“怎么让模型说好”上下文工程解决的是“怎么让模型在正确的信息状态里做决策”。第三时代模型要处理多轮工具调用所以上下文需要包含系统指令、用户目标、历史轨迹、工具返回结果、中间推理状态。这意味着你要认真设计上下文的结构。哪些信息必须放进去哪些可以放在外部数据库哪些历史需要截断都会影响 Agent 的质量和成本。3.3 记忆被外部化对话模型自带有限的上下文窗口但 Agent 执行复杂任务时记忆不能只躺在模型上下文里。第三时代会把记忆拆成三层短期记忆当前任务的执行轨迹。长期记忆用户偏好、历史订单、业务规则等存放在数据库或向量库中。外部状态订单状态、库存数量、任务进度存业务系统里。模型只持有与当前决策相关的部分其他部分通过检索工具按需获取。这样做既节省 token又避免模型上下文被无关信息污染。3.4 多步任务需要状态机与编排没有工具调用时模型是一问一答。有了工具调用后模型可能有 3 到 10 步的操作序列这些步骤之间还可能有分支和条件判断。你不能只写一个简单的请求-响应循环就要引入轻量级状态机甚至编排框架。编排层的工作包括判断步骤是否结束、记录每步调用的参数和结果、设置最大步数、处理异常分支、决定何时需要人工介入。3.5 评估体系从“回答质量”走向“任务成功率”传统 Chatbot 评估看语句通顺度、内容准确性。Agent 评估必须看另一套指标任务完成率、工具调用成功率、平均步数、平均延迟、单任务成本、异常回滚率。回答再漂亮任务没执行成功系统就是不可用的。这就把 AI 从“写作文”的评价体系拉回到“做软件”的评价体系。对团队来说这是一个特别重要的思维转换。3.6 基础设施开始为 Agent 优化OpenAI 在自研芯片、算力基础设施上的投入以及其他大厂跟进部署大规模 Agent 推理集群本质上都是在为第三时代铺路。Agent 任务的推理次数远高于单轮对话一个任务可能消耗几十次模型调用。没有成本更低的推理基础设施Agent 很难大面积商业化。从开发者社区的信息也能看到OpenAI 的工具链正在从“对话界面”扩展到命令行工具和编程代理。这些信号都指向同一个方向让 AI 不只是生成文本而是低成本地执行大量任务。4. 第三时代的产品形态从对话框到工作流4.1 对话框只是入口很多人以为 Agent 就是把 Chatbot 做聪明一点。实际上第三时代的产品形态会从“对话框”演变成“入口 工作流 反馈”的结构。对话框成为用户发起任务的入口但任务在后台由多条工作流处理。用户说“帮我查一下 A1001 的库存并按安全库存生成补货单”。传统 Chatbot 只能回复一段文字说明它没有权限、无法操作。第三时代的应用会实际调用库存接口查到实时数据再判断是否缺货随后触发补货单审批流。用户最后收到的不是一个“建议”而是一个“已完成的动作”或者“等待确认的审批事项”。4.2 一个典型的第三时代应用长什么样这里用一个客服工单处理场景来说明。假设用户提交了一个工单“我买的键盘无法连接电脑想退换货。”第一步Agent 调用客户信息接口获取订单详情。第二步Agent 根据售后规则判断该订单是否在退换货期内。第三步Agent 创建退换货工单并在 CRM 系统里标记状态。第四步Agent 生成给用户的回复说明退换货流程和物流地址。从用户视角他只是在对话框里说了一句话但这背后发生了四次工具调用、至少三轮模型推理。这就是第三时代产品与传统 Chatbot 的本质区别。4.3 产品经理和开发者的视角变化对产品经理来说功能定义从“界面上的按钮”变成“Agent 能执行的任务”对开发者来说研发对象从页面、接口变成工具集、权限策略、回滚机制和观测系统。这两类角色都需要重新理解“系统边界”。过去我们习惯把功能拆成多个页面和 API 让用户手动点。现在Agent 会把本来由人点击的操作串联起来。这要求业务逻辑必须足够“语义化”能够被模型理解并翻译成工具调用。5. 实操用 OpenAI API 快速搭建一个最小 Agent5.1 环境准备与前置条件我们的目标不是做一个复杂框架而是演示 Agent 的最小闭环模型理解用户请求调用工具拿到结果最终给出回答。环境要求很简单Python 3.9 以上。安装 openai 官方 Python SDK 和 python-dotenv。一个可用的 OpenAI API Key模型选择以账号实际可用为准本文示例使用常见的 gpt-4o-mini。建议使用虚拟环境隔离依赖python -m venv .venv source .venv/bin/activate pip install openai python-dotenv在项目根目录创建.env文件OPENAI_API_KEYsk-your-key加载环境变量import os from dotenv import load_dotenv load_dotenv() from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY))这里真正容易踩坑的地方是不要把 API Key 硬编码在代码里也不要把.env文件提交到 Git 仓库。后面接 CI/CD 时也建议通过密钥管理服务注入环境变量。5.2 第一版让模型学会调用工具我们实现一个最简单的库存查询工具。为了演示使用内存字典代替真实数据库。import json from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) inventory { A1001: {name: 无线路由器, stock: 23}, B2002: {name: 机械键盘, stock: 0}, } def query_inventory(sku: str) - str: item inventory.get(sku) if item is None: return json.dumps({error: SKU 不存在}) return json.dumps({sku: sku, name: item[name], stock: item[stock]}) TOOLS [ { type: function, function: { name: query_inventory, description: 根据 SKU 查询商品库存返回 JSON 字符串, parameters: { type: object, properties: { sku: { type: string, description: 商品 SKU 编号例如 A1001 } }, required: [sku] } } } ]代码里的关键点有三个工具描述要清楚模型根据描述决定是否调用。描述模糊模型就会乱猜。参数定义要严格required 字段不能漏。工具返回值必须是序列化友好的文本模型拿到后会继续推理。5.3 第二版多轮工具调用循环真正的 Agent 需要支持多轮模型可能第一次只请求查库存拿到结果后还需要继续判断。因此代码必须循环处理 model 返回的 tool_calls并把结果回传给模型。def run_agent(user_input: str, max_steps: int 5): messages [ {role: system, content: 你是一个库存查询助手只能使用 query_inventory 工具不能编造库存数据。}, {role: user, content: user_input} ] for step in range(max_steps): response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto, ) message response.choices[0].message # 模型不再调用工具说明任务已结束 if not message.tool_calls: return message.content # 保留模型本轮的消息及其 tool_calls messages.append({ role: message.role, content: message.content, tool_calls: [tc.model_dump() for tc in message.tool_calls] }) # 遍历模型请求的工具调用 for tool_call in message.tool_calls: if tool_call.function.name query_inventory: args json.loads(tool_call.function.arguments) tool_result query_inventory(args[sku]) else: tool_result json.dumps({error: 未知工具}) messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result }) return 达到最大步数未完成任务 if __name__ __main__: print(run_agent(A1001 还剩多少库存)) print(run_agent(B2002 库存不足怎么办))这版代码有几个值得解释的细节关闭工具调用的条件不是“某个关键词”而是 message.tool_calls 为空。每次工具结果都要和 tool_call_id 对应否则模型无法关联结果。设置 max_steps 非常重要防止模型陷入死循环。tc.model_dump()是为了把 tool_calls 序列化成普通字典不同 SDK 版本可能略有差异但思路一致。如果模型不返回 tool_calls极大可能是因为 prompt 里没有限制它必须用工具。你可以把 system prompt 改成“你必须调用 query_inventory 工具来回答库存问题”或者把 tool_choice 从auto改成required来测试。5.4 运行结果与效果验证运行上面代码最直接的验证方式是打印中间步骤。建议先写一个带日志的版本if __name__ __main__: result run_agent(A1001 还剩多少库存) print(最终回答:, result)预期输出是模型基于工具结果生成的自然语言例如A1001 无线路由器当前库存为 23 件。这里要额外提醒模型生成的自然语言可能会变但工具返回的真实数据是确定的。你判断成功与否不应该看模型说了什么而应该看它是否真的调用了工具、调用的参数是否正确、结果是否被正确引用。建议在日志中打印每一次 tool_call 的名称、参数和 tool 返回结果。5.5 为工具调用加上安全边界上面示例中模型只要返回一个函数名代码就会执行。这在实际项目中很危险。真实系统里你还需要做权限校验、参数白名单、操作类型限制。下面是一个安全调用示例TOOL_MAP { query_inventory: query_inventory, } ALLOWED_TOOLS {query_inventory} def call_tool_safely(tool_name: str, args: dict): if tool_name not in ALLOWED_TOOLS: raise PermissionError(f工具 {tool_name} 未在白名单内) func TOOL_MAP[tool_name] return func(**args)把 “模型请求调用工具” 和 “代码真实执行工具” 之间加一道闸是最基本的安全边界。6. 如何评估一个 Agent不能只看演示视频6.1 评估指标的四个维度Agent 上线前你至少要看这四个维度的指标维度指标示例说明成功率任务完成率在所有测试场景中完成预期业务动作的比例稳定性工具调用成功率模型是否输出了可解析的工具参数效率平均步数、平均延迟完成任务消耗多少步每步延迟多少成本单任务 token 消耗输入 token 与输出 token 总量换算成成本只有成功率不够。一个 Agent 如果平均跑 8 步延迟 15 秒费用 0.8 美元即便成功率很高也不一定能商业化。6.2 一个简单的评估脚本下面是一个面向测试用例的轻量评估骨架你可以把它扩展到自己的数据集import time import statistics def evaluate_agent(run_agent, test_cases): results [] success_count 0 for case in test_cases: start_time time.time() try: output run_agent(case[input]) success bool(output) and case[expect_success] except Exception as exc: output str(exc) success False latency round(time.time() - start_time, 2) success_count 1 if success else 0 results.append({ input: case[input], success: success, latency: latency, output_preview: output[:80] }) success_rate success_count / len(test_cases) avg_latency statistics.mean([item[latency] for item in results]) return { success_rate: success_rate, avg_latency: avg_latency, results: results, } test_cases [ {input: A1001 还有多少库存, expect_success: True}, {input: 查询 B2002 的库存情况, expect_success: True}, {input: 讲述一个程序员的故事, expect_success: False}, ] if __name__ __main__: report evaluate_agent(run_agent, test_cases) print(f成功率: {report[success_rate]}) print(f平均延迟: {report[avg_latency]}s)这段脚本里的expect_success表示该输入是否应该被 Agent 接受。比如“讲述一个程序员的故事”不应该触发库存查询如果模型也调用了工具说明意图过滤有问题。成本统计需要你在 run_agent 里把每次 response.usage 的 token 数累加再按实际模型单价计算这里不再展开。6.3 线上灰度与回滚Agent 很难一次性做到高成功率所以上线策略比传统功能更保守。建议按“影子模式 - 人工审批模式 - 自动执行模式”三步走。影子模式Agent 执行所有动作但不真正写库只记录日志。人工审批模式Agent 给出操作建议由人点击确认后执行。自动执行模式只在成功率稳定、风险可控的任务上放开自动执行。回滚策略上除了代码版本回滚还要准备“操作补偿”。比如 Agent 已经创建了订单你必须有取消订单的工具否则无法恢复错误状态。7. 常见问题与排查思路7.1 Agent 常见问题一览问题现象可能原因排查方式解决方案模型一直不调用工具tools 参数未正确传递或 system prompt 未限定工具打印 response 的 tool_calls 字段检查工具定义格式把 tool_choice 设为 required 测试工具参数解析失败模型返回的 arguments 为空或不是合法 JSON捕获 JSONDecodeError 并打印原始参数简化参数结构增加重试机制用枚举值限制取值Agent 执行了不该执行的操作工具权限过大被 prompt 注入诱导检查日志中的 tool_call 序列设置工具白名单限制危险工具重要操作加人工确认上下文越来越长费用飙升多轮工具结果全部塞进历史消息统计每次请求的 messages 大小和 token 消耗压缩工具结果只保留最近几轮外部化记忆Agent 看似成功但结果错误评测只看是否完成动作未校验业务正确性对比 tool 返回值和预期结果增加业务断言对工具返回值做二次校验7.2 模型一直不调用工具这是一个新手最容易遇到的问题。先检查两点tools 参数是否真的传入到了 chat.completions.create 中。返回的 message.tool_calls 是否为 None。如果 tool_calls 为空说明模型认为不需要调用。你可以把 system prompt 改成“你只能通过 query_inventory 工具获取库存信息不得猜测。” 或者直接用 tool_choicerequired 强制模型调用工具确认工具链路本身通不通。7.3 上下文太长与成本不可控Agent 每一步都会把历史消息传给模型工具结果也可能很大。解决思路有三条截断历史只需要保留最近两轮 tool 调用信息。压缩工具结果库存接口如果返回 100 条记录模型未必都需要可以只返回汇总。设计外部记忆长期信息存数据库或向量库Agent 需要时通过检索工具获取。建议在架构设计阶段就把“外部记忆”作为第一选择不要把模型上下文当数据库用。8. 最佳实践与工程建议8.1 给 Agent 最小权限Agent 默认不应该拥有权限。你要像对待一个刚入职的新员工一样对待它只给必要工具只给必要数据范围只允许在必要时间段执行。生产环境里把“查询”和“写操作”分开设计写操作全部走审批。8.2 让 Agent 的每一步可观测不要只记录最终结果。最好的做法是输出一个结构化的 trace 日志{ agent_run_id: uuid-123, step: 2, tool: query_inventory, args: {sku: A1001}, result: {\sku\:\A1001\,\stock\:23}, latency_ms: 320, tokens: {prompt: 1200, completion: 80} }这些日志可以用于问题排查、成本核算和评测集构建。第三时代最值钱的数据资产就是这些 Agent 执行轨迹。8.3 控制成本与延迟控制成本最有效的方式是限制最大步数、限制单次工具结果大小、使用小模型处理简单分支、用规则引擎前置过滤掉明显不需要 Agent 的任务。延迟优化则需要考虑模型选择、请求并发和工具接口耗时。8.4 从单任务场景开始不要第一个项目就做一个“全知全能”的智能体。先选一个边界清晰、步骤少、风险低的任务让 Agent 跑通再逐步扩展。库存查询、订单进度查询、报销单初审都是比较好的起步场景。8.5 团队协作要重新分工Agent 项目会改变团队协作方式。Prompt 工程不再只是提示词写手的事它与工具设计、权限策略、评测数据强耦合。建议团队里至少有一个人专门负责“工具体验”工具描述是否清晰、参数是否简洁、返回结果是否容易被模型理解。工具设计得好不好决定了 Agent 能力的上限。9. 写在最后先让 Agent 做一件小事AI 第三时代不是一个遥不可及的概念。你不需要等到模型更强、框架更成熟才动手而是可以用一个库存查询工具把“模型生成内容”和“模型执行操作”之间的链路亲手打通。如果你的团队正在决定要不要上 Agent我的建议是不要先搭平台不要先画宏大蓝图。选一个三步以内就能完成的任务让 Agent 连续稳定地执行 100 次。在这个过程里你会遇到参数解析失败、工具权限失控、上下文膨胀、成本失控等各种问题。这些问题不会因为换一个更强的模型而消失它们是第三时代应用开发的“规定动作”。先让 Agent 做一件小事这句话听起来很平常但确实是你进入 AI 第三时代最有效的启动方式。
