Skip to content

Agent 系统是否只是"提示词增强工程"?

更新: 6/13/2026 字数: 0 字 时长: 0 分钟

部分人对于Agent的观点:Agent 中的工具、Skill、MCP、Function Calling、运行规则,本质都是在优化模型输入提示词,全部属于提示词工程,所以目前的各种 Agent 系统实际上都是提示词增强工程而已。

这个判断抓住了一部分真相,也漏掉了一部分。下面不站队,把它说对的地方和说偏的地方分开摆出来,每条都尽量给出可验证的技术依据。

Agent 系统的提示词组装流程

一、该说法正确的依据

1. 工具定义最终确实是以文本形式拼进上下文的

Function Calling 的工具列表、参数 schema、描述字段,在请求发出前都会被序列化成结构化文本(通常是 JSON Schema),和 system prompt、用户消息一起进入模型的输入窗口。OpenAI 的 tools 字段、Anthropic 的 tools 参数,本质都是把工具描述编码进上下文。模型并不能"直接调用"任何函数,它输出的是一段符合格式约定的文本,由外部代码解析后再执行。从"模型看到了什么"这个视角看,工具确实就是上下文里的一段文本。

这一点可以验证:把工具描述写得清楚还是含糊,直接影响模型选不选对工具、填不填对参数。描述质量等价于提示质量,这正是提示词工程的核心命题。

2. Skill、运行规则在输入侧的载体也是文本

Skill 的本质是一份带元信息的指令文档(描述什么时候用、怎么用),运行规则是一组行为约束。它们被加载进上下文的方式,和 system prompt 没有结构性区别——都是自然语言或半结构化文本,靠模型的指令遵循能力生效。一个 Skill 写得好不好,很大程度取决于它的触发描述和操作步骤是否清晰,这和写提示词的优化目标是一致的。

可验证点:同一个 Skill,把描述改得更精准,模型的触发准确率会变化。这说明它在输入侧的作用机制确实是"提示"。

3. 模型本身是无状态的纯文本函数,所有输入都收敛到一次前向计算

大语言模型每次推理就是 f(tokens) → tokens,它不保存上一轮状态,不感知外部世界。无论上层包了多少层抽象,真正喂给模型的就是一段 token 序列。从这个底层事实出发,"所有机制最后都变成模型输入的一部分"是成立的——MCP 拉来的资源、工具返回的结果、历史对话,进入模型时全是文本。把这一层叫"输入构造",并没有错。

该说法成立的三条依据

二、该说法错误的偏差

1. 工具执行会改变真实世界,这不是文本能覆盖的部分

提示词工程的全部作用域在"模型输入到模型输出"之间。但 Function Calling 的价值不在模型吐出那段 JSON,而在外部运行时拿着这段 JSON 去真正执行了一次操作:写数据库、发 HTTP 请求、改文件、扣款。这一步发生在模型之外,有副作用、可能失败、需要重试和回滚。把工具调用等同于提示词优化,等于把"模型决定调用"和"系统实际执行"混为一谈——前者是提示问题,后者是工程问题,后者根本不在模型上下文里发生。

验证方式:同样一段工具调用文本,执行环境不同(权限、网络、沙箱)结果完全不同。文本一样、结果不一样,说明决定结果的不是文本本身。

2. Agent 的循环、状态与调度是控制流,不是输入内容

一个 Agent 跑起来是 感知 → 决策 → 执行 → 观察 → 再决策 的多轮循环,中间有记忆存取、上下文裁剪、错误处理、并发调度、终止条件判断。这些是程序的控制流逻辑,由 Agent 框架的代码实现,不是写进某一次提示里的内容。提示词工程优化的是"单次输入长什么样",而 Agent 工程要解决的是"多次调用怎么编排、状态怎么传递、什么时候停"。后者属于系统设计,和提示词不在一个层面。

可验证点:同一个模型、同一套提示,换一个调度策略(比如把串行改成并行、把单轮改成 ReAct 多轮),任务完成率和成本会显著变化。变的不是提示,是编排。

3. MCP 是协议和工程接口,不只是"把资源塞进提示"

MCP(Model Context Protocol)定义的是客户端和服务端之间的通信规范:怎么发现资源、怎么鉴权、怎么传输、怎么管理会话。它解决的是不同工具/数据源如何被标准化接入的工程问题,类比的是 USB 或 HTTP 这类接口标准,而不是"一段更好的提示词"。MCP 拉回来的数据最终确实会进上下文,但 MCP 本身的核心价值在连接和标准化,这部分发生在模型之外。

验证方式:MCP 的鉴权失败、连接超时、资源不可达,这些都是协议层和网络层的问题,和提示写得好不好无关。

4. 安全边界、权限、沙箱是模型管不到的工程约束

Agent 系统里大量工作在做隔离与防护:工具调用要不要审批、沙箱内存和超时限制、敏感操作的权限校验、防止越权和数据外泄。这些约束由外层代码强制执行,模型即使在提示里被"说服"也越不过去。把整个系统归结为提示词工程,会直接忽略掉这块——而它恰恰是生产级 Agent 和一个聊天玩具的分水岭。

该说法存在的工程偏差

三、中立总结

这个观点对了一半:从"模型只读文本"这个底层事实看,工具、Skill、MCP、Function Calling 的输入侧载体确实都会收敛成上下文里的 token,提示词工程是其中真实且重要的一环。但它把"输入构造"误当成了"系统全貌"。Agent 真正的工程量集中在模型之外——工具的实际执行与副作用、多轮循环的控制流与状态管理、MCP 这类接入协议、以及权限和沙箱构成的安全边界。这些既不发生在上下文里,也不靠改提示词解决。

更准确的定位是:提示词工程是 Agent 系统的必要条件,而非充分条件。它是地基,决定模型能不能听懂、选得对;但地基之上还有执行层、调度层、安全层。把 Agent 等同于"提示词增强工程",相当于说一栋楼就是它的地基——地基确实撑着整栋楼,但楼不只是地基。

提示词工程与 Agent 系统的分层定位