从 Prompt 到 Programmable Agent：技术演进脉络与工程范式变革

搜索引擎技术

239人浏览 · 2026-04-28 02:15:45

搜索引擎技术 · 2026-04-28 02:15:45 发布

从 Prompt 到 Programmable Agent：技术演进脉络与工程范式变革

副标题：大模型时代下应用开发的三次革命与未来十年的新赛道

关键词：Prompt Engineering、大语言模型、智能体（Agent）、可编程智能体、工程范式、LLMOps、工具调用

摘要

2022年ChatGPT的发布掀开了大模型时代的序幕，短短两年时间，我们见证了从最开始只会用自然语言问ChatGPT问题，到现在成千上万的可编程Agent正在替代人类完成各种复杂的工作。从10行代码就能实现的原生Prompt调用，到需要整套工程体系支撑的Agent平台，技术演进的背后是整个应用开发工程范式的彻底变革。本文将完整梳理从Prompt到Programmable Agent的四年技术演进脉络，拆解每个阶段的核心原理、工程实现、适用场景与最佳实践，同时深入分析大模型时代下软件工程从「确定性逻辑编程」到「不确定性智能体编排」的范式变革，为所有想要拥抱Agent时代的开发者、产品经理、技术负责人提供可落地的参考路径。读完本文，你不仅能搞懂Agent的技术本质，还能学会如何从零开始搭建一个能解决实际问题的可编程Agent。

1. 背景介绍

1.1 主题背景和重要性

在大模型出现之前，应用开发的逻辑已经延续了半个世纪：开发者把业务逻辑拆解成一行行确定的代码，输入什么、输出什么、异常怎么处理都写得明明白白，所有行为都是可预测的。但是大语言模型（LLM）的出现彻底打破了这个规则：大模型是概率模型，输出是基于上下文的next token预测，没有100%确定的结果，但是它能理解自然语言、能推理、能学习，这是传统代码永远做不到的。
我们可以把大模型比作刚毕业的高材生：智商很高、学习能力很强，但是没有工作经验、不知道工作流程、没有工具权限，你给他的指令越明确、给他的工具越多、给他的流程越清晰，他能完成的工作就越复杂。从最开始你随口说一句「帮我写个文案」（原生Prompt），到你给他写了详细的工作手册（提示工程），到你给他开放了公司的后台权限（工具调用），到最后你给他安排了固定的工作岗位，让他自己处理一整块业务（可编程Agent），这就是整个技术演进的核心脉络。
截至2024年，全球已有超过60%的企业在测试大模型应用，其中30%的企业已经落地了Agent相关的应用，覆盖客服、研发、运营、销售、生产等几乎所有场景。麦肯锡预测，到2030年，Agent相关的技术将为全球创造10万亿美元的经济价值，替代40%的重复性脑力劳动。理解从Prompt到Agent的演进路径，是所有技术从业者在大模型时代必须掌握的核心认知。

1.2 目标读者

本文适合以下人群阅读：

AI应用开发者：想要学习大模型应用开发、Agent开发的工程师
产品经理：想要设计大模型产品、Agent产品的产品负责人
技术架构师：想要搭建企业级大模型平台、Agent平台的架构师
AI创业者：想要在Agent赛道创业的创业者
企业技术负责人：想要推进大模型在企业内部落地的技术管理者

1.3 核心问题与挑战

在大模型应用落地的过程中，所有企业都会遇到以下核心问题：

可维护性差：最开始的Prompt都是写死在代码里的，改一次Prompt就要发一次版，多个人一起维护的时候很容易出现冲突，效果也没法评估
能力边界有限：纯Prompt的大模型没有办法获取实时数据，没有办法和企业内部系统交互，比如不能查订单、不能查库存、不能算数据，只能回答训练数据里有的内容
不确定性高：大模型经常出现幻觉，输出错误的信息，严重的时候会给企业带来损失
复杂任务处理能力弱：纯Prompt的大模型只能处理单轮、简单的任务，遇到多步骤的复杂任务，比如「帮我安排下周去上海的出差」，根本没有办法完成
这些问题的解决方案，就是本文要讲的从提示工程到工具调用再到可编程Agent的完整技术路径。

2. 核心概念解析

2.1 核心概念生活化比喻

我们用「雇助理」的例子来解释四个阶段的核心概念：

技术阶段	生活化类比	核心特点
原生Prompt调用	你临时找了个兼职大学生，随口说一句「帮我买杯咖啡」	全靠执行者自己理解，效果不稳定，只能做简单的事
提示工程（Prompt Engineering）	你给兼职大学生写了详细的备注：「买冰美式，少糖，不加奶，多放冰，送到了放门口不要敲门，我在开会」	通过明确的指令提升效果，还是只能做单轮任务
工具调用（Function Call）	你给大学生配了导航、外卖APP、公司门禁卡	能借助外部工具完成更复杂的任务，但是还是需要你告诉他什么时候用什么工具
可编程Agent（Programmable Agent）	你雇了个全职私人助理，你只要说「帮我安排下周去上海的出差」，他自己会订机票、订酒店、约客户、发日程给你，遇到问题还会回来问你	有自主规划能力、记忆能力、工具调用能力，能独立完成复杂的多步骤任务

2.2 核心概念属性对比

我们用表格来对比四个阶段的核心属性：

对比维度	原生Prompt调用	提示工程	工具调用	可编程Agent
抽象级别	低	中	中高	高
开发者要求	会调API就行	需要懂提示工程技巧	需要懂工具定义、接口开发	需要懂Agent编排、LLMOps
确定性	极低，完全依赖大模型	中等，优化Prompt能提升准确率	较高，工具返回结果确定	高，通过编排、校验管控不确定性
可维护性	极低，Prompt散落在代码里	中等，能统一管理Prompt	较高，能统一管理工具	高，有完整的配置、监控、迭代体系
可扩展性	极低，只能用大模型本身的能力	低，只能优化Prompt	中，能新增工具扩展能力	极高，能新增模块、工具、记忆扩展能力
适用场景	简单的、一次性的、对准确率要求不高的场景，比如写文案、想点子	有固定输出格式的简单推理场景，比如分类、信息提取、简单数学题	需要外部数据或外部能力的单轮场景，比如查天气、查订单、算数据	复杂的多步骤场景，比如自动化工作流、项目管理、私人助理、售后客服
平均错误率	30%以上	10%-20%	5%-10%	1%-5%

2.3 概念关系与架构图

2.3.1 实体关系ER图

2.3.2 交互关系序列图

2.4 边界与外延

很多人会混淆Agent和普通大模型应用，我们可以用三个特征来判断是不是真正的Agent：

自主规划能力：能不能自己把复杂任务拆解成多个子任务，不需要人工预先定义所有步骤
记忆能力：能不能记住历史对话、之前完成的任务、用户的偏好，不需要每次都重复输入信息
工具调用能力：能不能和外部系统交互，调用工具获取实时数据、执行操作，而不是只靠大模型本身的训练数据
只要同时满足这三个特征，就是Agent，否则只是普通的大模型应用。比如很多所谓的「智能客服」只是把常见问题的答案存在知识库，匹配到用户的问题就返回，没有规划能力，也不能调用工具，就不是Agent。

3. 技术原理与实现

3.1 技术发展历史脉络

我们先梳理从2020年到2024年的技术发展历史：

时间	标志性事件	技术阶段	核心能力	代表性产品	工程范式
2020年6月	OpenAI发布GPT-3，参数规模175B	原生Prompt阶段	上下文文本生成、零样本能力	GPT-3 API	传统API调用，直接传用户输入
2022年11月	OpenAI发布ChatGPT，支持多轮对话	提示工程阶段	上下文学习、思维链推理、角色设定	ChatGPT、New Bing	提示工程，通过优化Prompt提升效果
2023年3月	OpenAI发布GPT-4，支持Function Call	工具调用阶段	外部工具调用、结构化输出、能力扩展	ChatGPT Plugins、文心一言函数调用	工具编排，定义工具schema，调用外部能力
2023年4月	AutoGPT开源，掀起Agent热潮	可编程Agent萌芽阶段	自主任务规划、多步骤执行、记忆能力	AutoGPT、BabyAGI	Agent编排，加入规划、记忆、反思模块
2024年3月	OpenAI发布GPT-4o，Anthropic发布Claude 3 Opus	可编程Agent成熟阶段	多模态理解、低延迟工具调用、复杂任务处理	Devin、LangGraph、字节豆包Agent	智能体编程，低代码/无代码Agent平台
2025年（预测）	多Agent协作标准落地	多Agent协作阶段	多智能体分工协作、端云协同、行业定制	企业级Agent平台、行业Agent市场	多智能体编排，Agent生态形成

3.2 各阶段技术原理与数学模型

3.2.1 原生Prompt阶段

原生Prompt的核心原理是大模型的next token预测机制，给定输入的token序列 $w_1, w_2, ..., w_{t-1}$ ，模型预测下一个token $w_t$ 的概率：
$P(wt∣w1,w2,...,wt−1,θ)P(w_t | w_1, w_2, ..., w_{t-1}, \theta)$
其中 $θ\theta$ 是大模型的参数，所有输出都是基于这个概率分布采样得到的。
代码实现：

from openai import OpenAI
import os
from dotenv import load_dotenv

load_dotenv()
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

def native_prompt_call(query: str) -> str:
    """原生Prompt调用，直接传入用户查询"""
    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[{"role": "user", "content": query}]
    )
    return response.choices[0].message.content

# 测试
if __name__ == "__main__":
    print(native_prompt_call("什么是大语言模型?"))

这个阶段的缺点非常明显：输出完全依赖大模型本身的能力，没有任何约束，很容易出现幻觉，也不能处理需要外部数据的任务。

3.2.2 提示工程阶段

提示工程的核心原理是上下文学习（In-Context Learning），给定任务描述T、少量样例集合 $S = \{(x_1,y_1), (x_2,y_2), ..., (x_n,y_n)\}$ 和用户查询x，模型输出y的概率为：
$\theta)$
通过优化任务描述、样例、输出格式要求，可以大幅提升大模型输出的准确率和稳定性。常用的提示工程技巧包括思维链（CoT）、自我一致性（Self-Consistency）、思维树（ToT）、角色设定等。
我们用思维链（CoT）作为示例，代码实现如下：

def cot_prompt_call(query: str) -> str:
    """带思维链的Prompt调用，让模型先输出推理过程再给答案"""
    cot_prompt = f"""
    你是一个擅长解决问题的专家，遇到问题请先一步步思考，给出完整的推理过程，最后再给出答案。
    问题：{query}
    请按照以下固定格式输出：
    【推理过程】：
    你的详细推理步骤，每一步都要清晰
    【答案】：
    最终的答案
    """
    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[{"role": "user", "content": cot_prompt}],
        temperature=0
    )
    return response.choices[0].message.content

# 测试数学题
if __name__ == "__main__":
    print(cot_prompt_call("一个笼子里有鸡和兔子，头有10个，脚有28只，问鸡和兔子各有多少只?"))

这个阶段的准确率比原生Prompt提升了30%以上，但是还是只能处理单轮任务，不能扩展外部能力。

3.2.3 工具调用阶段

工具调用的核心原理是大模型经过微调之后，可以输出符合特定JSON格式的函数调用请求，而不是自然语言。给定用户查询x，模型输出函数名f和参数列表 $args = \{k_1:v_1, ..., k_n:v_n\}$ 的概率为：
$\theta)$
开发者执行函数 $f (a r g s)$ 得到结果r，再把r返回给大模型，大模型基于r生成最终的自然语言回答。
代码实现（查天气工具示例）：

import json
import requests

def get_weather(city: str) -> str:
    """查询指定城市的实时天气，实际场景可以替换为第三方天气API"""
    # 模拟天气数据
    weather_data = {
        "北京": "晴，25-32度，南风3级，空气质量优",
        "上海": "小雨，20-25度，东风2级，空气质量良",
        "广州": "多云，28-35度，无风，空气质量轻度污染"
    }
    return weather_data.get(city, f"暂不支持查询{city}的天气")

def function_call_example(query: str) -> str:
    """工具调用示例，自动判断是否需要调用查天气工具"""
    # 定义工具的JSON Schema，告诉大模型这个工具的作用和参数要求
    tools = [
        {
            "type": "function",
            "function": {
                "name": "get_weather",
                "description": "当用户询问某个城市的天气、气温、空气质量的时候，调用这个工具",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "city": {
                            "type": "string",
                            "description": "要查询天气的城市中文名称，比如北京、上海、深圳"
                        }
                    },
                    "required": ["city"]
                }
            }
        }
    ]
    # 第一次调用大模型，判断是否需要调用工具
    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[{"role": "user", "content": query}],
        tools=tools,
        tool_choice="auto"
    )
    response_message = response.choices[0].message
    # 如果需要调用工具
    if response_message.tool_calls:
        tool_call = response_message.tool_calls[0]
        function_name = tool_call.function.name
        function_args = json.loads(tool_call.function.arguments)
        # 执行工具函数
        function_response = globals()[function_name](**function_args)
        # 把工具返回结果传给大模型，生成最终回答
        second_response = client.chat.completions.create(
            model="gpt-3.5-turbo",
            messages=[
                {"role": "user", "content": query},
                response_message,
                {
                    "role": "tool",
                    "tool_call_id": tool_call.id,
                    "name": function_name,
                    "content": function_response
                }
            ]
        )
        return second_response.choices[0].message.content
    else:
        # 不需要调用工具，直接返回结果
        return response_message.content

# 测试
if __name__ == "__main__":
    print(function_call_example("今天北京的天气怎么样，适合出去玩吗?"))

工具调用阶段解决了大模型不能获取实时数据、不能和外部系统交互的问题，但是还是只能处理单轮工具调用的场景，遇到多步骤的复杂任务还是无能为力。

3.2.4 可编程Agent阶段

可编程Agent的核心原理是把大模型作为「大脑」，加上规划模块、记忆模块、工具调度模块、反思模块，组成一个闭环的自主执行系统。Agent的状态 $s_t$ 包含当前任务、历史对话、工具执行结果、记忆内容，Agent的执行过程可以用马尔可夫决策过程来描述：

规划模块根据当前状态 $s_t$ 生成下一步动作 $a_t = Plan(s_t)$
执行模块执行动作 $a_t$ 得到结果 $r_t = Execute(a_t)$
状态更新模块更新状态 $s_{t+1} = Update(s_t, a_t, r_t)$
重复上述过程直到任务完成，返回最终结果
Agent的优化目标是最大化任务完成的奖励：
$\sum_{t=0}^T \gamma^t r_t$
其中 $γ\gamma$ 是折扣因子， $r_t$ 是每一步的奖励（比如任务完成得好给正奖励，出错给负奖励）。
算法流程图：

代码实现（基于LangGraph的研究Agent示例）：
首先安装依赖：

pip install langchain langgraph openai serpapi python-dotenv

然后编写代码：

from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
from langchain_community.tools import SerpAPIWrapper
from langchain.agents import Tool
from langchain_core.messages import BaseMessage, HumanMessage
from typing import TypedDict, Annotated, Sequence
import operator
import os
from dotenv import load_dotenv

load_dotenv()

# 定义Agent的状态
class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], operator.add]
    next: str

# 初始化搜索工具
search = SerpAPIWrapper(serpapi_api_key=os.getenv("SERPAPI_KEY"))
tools = [
    Tool(
        name="Search",
        func=search.run,
        description="当你需要查询最新的信息、不知道的知识、实时数据的时候，可以用这个工具搜索互联网"
    )
]

# 初始化大模型，绑定工具
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0, api_key=os.getenv("OPENAI_API_KEY"))
llm_with_tools = llm.bind_tools(tools)

# 定义Agent推理节点
def agent_node(state: AgentState):
    messages = state["messages"]
    response = llm_with_tools.invoke(messages)
    return {"messages": [response]}

# 定义工具执行节点
def tool_node(state: AgentState):
    messages = state["messages"]
    last_message = messages[-1]
    tool_responses = []
    for tool_call in last_message.tool_calls:
        tool = next(t for t in tools if t.name == tool_call["name"])
        tool_response = tool.run(tool_call["args"])
        tool_responses.append(
            {
                "tool_call_id": tool_call["id"],
                "role": "tool",
                "name": tool_call["name"],
                "content": tool_response
            }
        )
    return {"messages": tool_responses}

# 定义路由函数，判断下一步是调用工具还是结束
def router(state: AgentState):
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "tools"
    else:
        return END

# 构建Agent工作流
workflow = StateGraph(AgentState)
workflow.add_node("agent", agent_node)
workflow.add_node("tools", tool_node)
workflow.set_entry_point("agent")
workflow.add_conditional_edges("agent", router)
workflow.add_edge("tools", "agent")

# 编译运行
app = workflow.compile()

def run_research_agent(query: str):
    inputs = {"messages": [HumanMessage(content=query)]}
    for output in app.stream(inputs):
        for key, value in output.items():
            print(f"=== 执行节点: {key} ===")
            print(value["messages"][-1].content)
            print("-"*50)
    return output["agent"]["messages"][-1].content

# 测试
if __name__ == "__main__":
    result = run_research_agent("2024年上半年中国新能源汽车销量排名前3的品牌是哪些，各自的销量是多少？")
    print("最终结果：", result)

这个Agent可以自主搜索互联网获取最新的销量数据，整理之后返回给用户，完全不需要人工干预。

4. 实际应用与工程落地

4.1 落地案例：电商智能售后Agent

我们以某头部电商平台的智能售后Agent为例，讲解Agent的落地过程：

4.1.1 项目背景

该电商平台原来的售后全部由人工客服处理，共有2000名售后客服，每人每天处理100个工单，人工成本每年超过2亿元，平均响应时间10分钟，用户满意度只有70%。

4.1.2 系统架构设计

4.1.3 核心功能

该售后Agent可以自动处理70%的售后工单：

用户申请售后之后，Agent自动查询订单信息、物流信息、售后规则，判断是否符合售后条件
如果符合退款条件，自动执行退款操作，给用户发送通知
如果需要退货，自动安排上门取件，同步物流信息给用户
如果不符合售后条件，自动给用户解释原因，提供解决方案
遇到复杂问题（比如用户投诉、商品损坏纠纷），自动转给人工客服，并且把所有上下文信息同步给人工客服，不需要用户重复描述问题

4.1.4 落地效果

上线之后，该平台的售后成本降低了60%，平均响应时间从10分钟降到了1秒，用户满意度提升到了92%，每年节省成本超过1.2亿元。

4.2 通用Agent落地步骤

所有行业的Agent落地都可以遵循以下6个步骤：

需求定义与边界划定：首先明确Agent要解决的问题，划定清晰的能力边界，越垂直的Agent效果越好，不要一开始就做通用Agent
模块选型：选择合适的大模型（复杂任务用GPT-4o/Claude 3，简单任务用Llama 3/通义千问）、记忆组件（Redis存短期记忆，PostgreSQL+pgvector存长期记忆）、工具集（第三方API/企业内部接口）
编排逻辑开发：用LangGraph/AutoGPT/自研框架开发Agent的编排逻辑，定义规划、记忆、工具调用、反思的规则
测试与评估：搭建自动化测试集，覆盖常见场景和边缘场景，评估Agent的准确率、完成率、错误率，不断优化Prompt和编排逻辑
灰度上线：先给1%的用户使用，收集bad case，迭代优化，再逐步扩大灰度范围
监控与迭代：上线之后全链路监控Agent的执行过程，收集bad case，每周迭代优化，Agent的能力是迭代出来的，不是一次开发完就完事的

4.3 常见问题与解决方案

常见问题	根本原因	解决方案
Agent幻觉，输出错误信息	大模型的概率特性，或者工具返回结果和输出不一致	1. 加入结果校验模块，让另一个大模型检查输出和工具结果是否一致；2. 加入反思步骤，让Agent自己检查结果是否正确；3. 重要场景加人工审核
任务死循环，Agent一直调用工具	任务拆解错误，或者工具返回结果不符合要求	1. 加最大执行步数限制，超过之后自动结束；2. 加超时机制，执行时间超过阈值自动转人工；3. 优化任务拆解模板，常见任务用预先定义的拆解模板
调用成本过高，一次任务要几块钱	所有步骤都用大模型，而且用的都是贵的大模型	1. 混合模型架构：用小模型做路由、意图识别、分类，复杂任务才用大模型；2. 缓存常用的工具调用结果和大模型输出；3. 用开源模型替代闭源模型，成本降低90%
可解释性差，出了问题不知道为什么	Agent的决策过程是黑盒，没有记录	1. 全链路记录所有步骤的输入输出：大模型调用参数、返回结果、工具调用参数、返回结果、耗时；2. 加可解释性模块，让Agent每一步决策都输出原因
安全问题，Agent越权操作	工具权限过大，没有校验	1. 最少权限原则：给Agent的工具权限越小越好，比如只能查数据不能改数据；2. 高危操作加二次确认，要么用户确认要么管理员确认；3. 加入Prompt注入检测，防止恶意用户攻击

4.4 最佳实践Tips

边界越清晰效果越好：Agent的能力边界一定要写在系统Prompt里，不要让Agent处理超出能力范围的问题
分层记忆设计：短期记忆存当前会话上下文，中期记忆存最近7天的任务记录，长期记忆存知识库和用户偏好
可观测性优先：Agent的执行链路100%可追溯，出了问题能快速定位
人类回退机制是标配：所有Agent都要有转人工的入口，遇到不确定的问题自动转人工
小步迭代：先做最小可用版本，上线收集反馈再迭代，不要追求完美一次做很多功能

5. 未来展望

5.1 技术发展趋势

Agent标准化：现在各个厂商的Agent框架、工具协议五花八门，未来会出台统一的标准，比如统一的Agent接口、统一的工具定义规范，不同厂商的Agent可以互相调用
多Agent协作：未来的复杂任务会由多个Agent协作完成，比如产品Agent负责写需求，研发Agent负责写代码，测试Agent负责测bug，运维Agent负责上线，整个研发流程完全自动化
端侧Agent：现在Agent都跑在云端，未来会有越来越多的Agent跑在手机、电脑、汽车等端侧设备上，数据不用上传，隐私性更好，响应速度更快
Agent市场：未来会有像现在的应用商店一样的Agent市场，用户可以下载各种Agent来用，开发者可以上传自己的Agent赚钱，形成完整的Agent生态
个性化Agent：每个用户都会有自己的专属Agent，学习用户的习惯、偏好，帮用户处理各种日常事务，比如安排行程、处理工作、购物、社交

5.2 潜在挑战

安全问题：Agent如果有太高的权限，比如能转钱、能删数据，一旦被Prompt注入攻击，会给用户带来巨大的损失，未来需要建立完整的Agent安全防护体系
伦理问题：Agent做的决策出了问题，谁来负责？是开发者？是用户？是大模型厂商？未来需要出台相关的法律法规明确责任划分
性能问题：现在Agent处理一个复杂任务要几分钟，未来需要优化到秒级，才能满足大多数场景的要求
易用性问题：现在搭建Agent还是需要很强的技术能力，未来会有低代码/无代码的Agent平台，普通人不用写代码也能搭建自己的Agent

5.3 行业影响

软件工程范式变革：原来的软件工程是「确定性逻辑编程」，未来的软件工程是「不确定性智能体编排」，开发者的工作从写业务逻辑变成定义Agent的角色、规则、工具，代码量会减少80%以上
劳动力结构变化：40%的重复性脑力劳动会被Agent取代，比如客服、数据录入、基础文案、基础代码开发，人类会转向更有创造性的工作，比如定义Agent的目标、优化Agent的能力、做决策
产业互联网升级：Agent会渗透到各个行业，比如制造业的Agent能自动优化生产流程，金融行业的Agent能自动做风险控制，医疗行业的Agent能辅助医生诊断，整个社会的生产效率会提升30%以上