目录

AI Agent为何从Prompt走向Platform？

01｜Prompt Engineering 解决的是“单次模型调用”

02｜企业 Agent 的问题不是“怎么问模型”，而是“模型运行在什么系统里”

03｜从 Prompt 到 Context：模型不缺指令，缺的是可信上下文

04｜Workflow 能编排流程，但 Runtime 才能承载生产运行

05｜为什么 AI Agent 越来越像操作系统？

06｜Platform Engineering 到底要建设什么？

07｜AI Agent Platform Engineer 会成为新的工程角色

08｜总结：Prompt 是入口，Platform 才是护城河

---

AI Agent为何从Prompt走向Platform？

摘要： 企业级 Agent 的难点不再是写好一次 Prompt，而是把模型、上下文、工具、权限、状态、观测与数据闭环组织成稳定平台。

---

很多人最开始接触 AI Agent，都会从 Prompt Engineering 开始。给模型一个角色，补一段背景，列几个约束，再要求它按照 JSON 输出。只要提示词写得足够清楚，Demo 往往能跑起来：模型能理解用户问题，能调用工具，能生成一段看起来不错的回答。但一旦进入企业场景，问题很快就会变复杂。

用户不会只问一个干净的问题。他可能发一段语音、一张后台页面截图、一句模糊描述，还夹杂着账号、项目、工单、审批流、第三方集成、配置项等信息。系统不仅要理解问题，还要判断用户权限、查询业务数据、调用不同 Agent、识别高风险动作、保存执行链路、支持人工审核、追踪失败原因，并且把线上问题沉淀成后续优化的数据。这时候，Prompt 已经不是系统的核心了。

真正的核心开始变成：如何把模型、上下文、工具、权限、状态、观测、评测和数据闭环组织成一个稳定可运行的平台。 这就是 AI Agent 从 Prompt Engineering 演进到 Platform Engineering 的根本原因。

01｜Prompt Engineering 解决的是“单次模型调用”

Prompt Engineering 的价值并不低。它解决了早期大模型应用里最直接的问题：

• 我希望模型扮演什么角色？

• 我希望模型完成什么任务？

• 我能给模型哪些背景？

• 我希望模型按什么格式输出？

• 哪些事情模型不能做？

• 遇到不确定信息时应该怎么处理？

所以，在单轮问答、内容生成、简单分类、结构化抽取、轻量工具调用场景里，Prompt Engineering 非常有效。

比如一个企业 SaaS 客户支持助手，可以通过 Prompt 要求模型：

• 你是企业 SaaS 平台的客户支持助手。

• 请根据用户问题判断业务类型。

• 如果用户提到资金类操作、敏感数据修订、权限变更、数据删除或批量配置等高风险动作，只能提示人工审核，不能自动执行。

• 输出结构化结果，包含任务类型、风险等级和是否需要人工审核。

这类 Prompt 可以让模型表现得更稳定，也能把输出格式收敛到业务系统可以解析的结构。但它仍然主要解决的是“这一次模型调用怎么更好”。企业级 Agent 要解决的不是一次调用，而是一个完整的生产运行过程。

02｜企业 Agent 的问题不是“怎么问模型”，而是“模型运行在什么系统里”

在企业场景里，用户的问题通常不是纯文本问答，而是跨系统、跨状态、跨权限的业务任务。

以通用企业 SaaS 场景为例，常见问题可能是：

• 报表结果与业务记录不一致

• 第三方系统数据不同步

• 员工账号无法访问某个模块

• 审批流程卡在某个节点

• 配置变更后没有生效

• 报表数据和业务系统不一致

这些问题看上去是一句话，实际背后往往要经过多步判断：

1. 用户是谁，属于哪个租户、组织、角色？

2. 用户发的是文本、图片、语音，还是混合输入？

3. 图片里有没有账号、业务对象、错误码、审批状态？

4. 语音里有没有补充时间、模块名称、操作路径？

5. 这个问题涉及账号权限、审批、数据同步、报表还是配置？

6. 当前用户有没有查询对应业务数据的权限？

7. 需要调用哪些只读工具或业务 Agent？

8. 结果之间有没有冲突？

9. 是否涉及资金类操作、敏感数据修订、权限变更、数据删除或批量配置等高风险动作？

10. 是否要进入人工审核？

11. 本次执行过程如何追踪、复盘、评测和优化？

这些问题不是靠一段更长的 Prompt 就能解决的。

因为这里已经出现了多个工程问题：

• 上下文从哪里来？

• 上下文如何合并、裁剪和可信度分层？

• 工具由谁注册？

• Agent 由谁选择？

• 权限由谁校验？

• 计划由谁验证？

• 失败后如何重试？

• 中断后如何恢复？

• 高风险动作如何拦截？

• 执行过程如何观测？

• 线上问题如何沉淀成数据集？

当这些问题出现时，AI Agent 的工程重心就会自然从 Prompt 转向 Platform。

图｜Prompt、Context、Workflow、Runtime 与 Platform 的逐层演进

03｜从 Prompt 到 Context：模型不缺指令，缺的是可信上下文

很多 Agent 效果不好，并不是因为 Prompt 写得不够华丽，而是因为上下文不稳定。

模型真正需要的是：

• 用户原始问题

• 多轮历史摘要

• RAG 检索证据

• 业务系统查询结果

• 图片 OCR 文本

• 图片 VLM 理解

• 语音 ASR 文本

• 账号、项目、工单、审批、配置等结构化信息

• 当前用户权限

• 当前租户、组织、应用模块状态

• 历史执行结果

• 失败原因和人工反馈

这些内容不能全部无脑塞进 Prompt。企业 Agent 要做的是 Context Engineering，也就是把不同来源的信息整理成可控、可追踪、可裁剪、可验证的上下文。

在一个更工程化的 Agent 系统里，Prompt 只是最终消费上下文的一层。真正关键的是前面的上下文流水线：

执行流程： 用户输入 → 文本 / 图片 / 语音解析 → OCR / ASR / VLM / RAG / 业务查询 → 证据归一化 → 字段抽取 → 风险信号识别 → 权限上下文注入 → 标准化任务描述 → Runtime 调度执行

这也是为什么很多项目做到后面会发现：Prompt 文件越来越不重要，Context Schema、Evidence Model、Snapshot、Trace、Dataset 反而越来越重要。

04｜Workflow 能编排流程，但 Runtime 才能承载生产运行

很多人会把 Agent 工程化理解成“用 LangGraph 画一个流程图”。Workflow 很重要，但 Workflow 不等于 Runtime。

Workflow 解决的是：

• 有哪些节点？

• 节点之间怎么流转？

• 什么时候进入下一步？

• 什么时候结束？

但企业 Agent Runtime 还要解决更多生产问题：

• 请求生命周期如何管理？

• 任务标识、请求标识、会话标识 如何关联？

• Checkpoint 存在哪里？

• 人工审核中断后如何 resume？

• Agent Registry 如何维护？

• 当前用户可用 Agent 如何过滤？

• Planner 生成的计划是否合法？

• 权限校验由谁强制执行？

• 工具调用如何超时、重试、隔离失败？

• 执行结果如何聚合？

• Trace、成本、延迟、错误如何记录？

• 线上 case 如何沉淀为评测集和反例集？

所以，企业级 Agent 不能只停留在 Workflow 层。

一个更完整的 Runtime 往往会包含：

• 接入与会话上下文层

• 多模态预处理

• 标准化任务协议

• Agent Registry

• Planner

• 计划校验机制

• 执行前权限校验

• 智能体执行层

• 结果聚合机制

• 人工审核节点

• Checkpoint

• Trace / Observability

• Evaluation / Dataset

在一个通用企业 SaaS Agent 平台里，实际链路也不应该是“用户问题直接进 Prompt”，而是：

执行流程： Multimodal Preprocess → 输入快照 / 上下文快照 → 标准化任务描述 → Agent Runtime → Planner → 计划校验机制 → 执行前权限校验 → 智能体执行层 → 结果聚合机制 → 人工审核节点 → 回复生成环节

这条链路说明了一个关键事实：Prompt 只是 Agent 系统中的局部能力，Runtime 才是企业 Agent 的主体。

05｜为什么 AI Agent 越来越像操作系统？

如果把企业级 Agent 再往深处看，会发现它越来越像一个小型操作系统。不是因为它真的要替代操作系统，而是因为它需要处理类似的问题。

• 模型：类似计算核心，负责推理和生成。

• Context：类似内存，决定当前任务能看到什么。

• Tool：类似系统调用，让模型访问外部能力。

• Agent Registry：类似进程和服务注册表。

• 执行前权限校验：类似权限模型和访问控制。

• Checkpoint：类似进程快照，支持中断和恢复。

• Trace：类似系统日志，用于排查和审计。

• Evaluation：类似测试系统，用于回归和质量控制。

• Data Platform：类似运行数据沉淀层，让系统持续优化。

早期 Prompt Engineering 更像是在教一个模型“应该怎么回答”。Agent Platform Engineering 则是在设计一个系统：让模型在正确的上下文里、通过受控的工具、按照可验证的计划、在权限边界内完成任务，并且留下完整的运行证据。这也是为什么企业不会满足于一个聊天机器人 Demo。

企业真正需要的是：

• 可接入业务系统

• 可隔离租户

• 可控制权限

• 可审计执行过程

• 可人工介入

• 可评测效果

• 可持续优化

• 可灰度演进

这些能力都不是 Prompt 本身能承担的。

06｜Platform Engineering 到底要建设什么？

如果把企业 Agent 平台拆开看，至少需要建设六类能力。

统一接入层

统一接入层通常由 BFF 或 Chat API 承担。

它不是简单转发请求，而是负责：

• 多端协议适配

• 用户和租户上下文注入

• 会话标识 鉴权

• 请求标识 幂等

• 历史消息组装

• SSE 进度返回

• 输入快照、任务标识与最终结果关联

没有统一接入层，Agent 很容易变成多个零散接口，后期很难维护。

Context Engineering

Context Engineering 负责把用户输入、历史、RAG、工具结果、多模态证据和业务状态整理成稳定上下文。

它要考虑：

• 哪些信息可信？

• 哪些信息只是弱证据？

• 哪些字段需要工具确认？

• 哪些历史可以进入当前轮？

• 哪些内容会触发风险？

• 上下文过长时如何裁剪？

• 如何保存快照便于复盘？

在企业多模态 Agent 中，OCR、ASR、VLM 的结果不能直接等同于业务事实。它们应该作为 上下文证据 进入合并层，再由后续业务工具和权限规则确认。

Agent Runtime

Runtime 是平台的执行核心。

它负责把上游输入转成可执行任务：

执行流程： 统一任务描述 → Planner 生成计划 → 校验计划 → 检查权限 → 执行 Agent → 聚合结果 → 判断是否继续 → 生成最终回复

Runtime 的重点不是“让模型自由发挥”，而是让模型生成的计划进入确定性工程边界。

权限与风险控制

企业 Agent 最大的风险，不是回答错一句话，而是错误执行了高风险动作。

比如：

• 资金类操作

• 敏感数据修订

• 修改用户权限

• 删除或覆盖业务数据

• 批量修改配置

• 触发外部系统重试或补偿任务

这些动作不能因为模型判断“看起来应该执行”就自动执行。

合理的设计应该是：

• 模型可以识别风险

• Planner 可以提出建议

• Runtime 必须强制校验

• 高风险动作转成人工审核提案

• 审批通过后再由确定性系统执行

这里的关键是：安全边界必须由代码和权限系统兜住，不能只靠 Prompt 约束模型。

Trace 与 Observability

Agent 系统上线后，一定会遇到各种问题：

• 为什么这次路由错了？

• 为什么调用了错误工具？

• 为什么权限被拒绝？

• 为什么第二轮 Loop 没有继续？

• 为什么用户看到的结论和工具结果不一致？

• 为什么延迟突然升高？

• 为什么成本异常？

如果没有 Trace，这些问题很难排查。

企业 Agent 需要记录：

• Prompt

• LLM 输入输出

• RAG 检索结果

• 工具调用参数和结果

• Agent step

• 权限检查

• 风险判断

• Loop 轮次

• 最终回复

• 用户反馈

• 延迟、错误、Token、成本

这也是 Langfuse、LangSmith、Phoenix 这类观测系统在 Agent 项目里越来越重要的原因。

AI Data Platform

Agent 平台最终一定会走向数据闭环。

因为企业真正关心的不是“这次有没有答出来”，而是：

• 哪些问题经常失败？

• 失败是检索问题、路由问题、工具问题，还是模型规划问题？

• 哪些 case 应该进入评测集？

• 哪些 case 应该变成反例集？

• 哪些用户问题可以沉淀成 FAQ？

• 哪些工具结果可以反向补充 RAG 知识？

• 哪些 Prompt / Plan 样例可以用于后续优化？

这就是 AI Data Platform 的价值。

它把线上真实问题和执行链路沉淀下来，形成：

• 训练集

• 验证集

• 评测集

• 反例集

• Hard Case Dataset

• FAQ 候选

• RAG 知识补充

• Prompt / Plan 样例

• Judge 评分记录

没有数据平台，Agent 每次失败都只是一次失败。 有了数据平台，Agent 的失败才有机会变成下一轮优化的资产。

07｜AI Agent Platform Engineer 会成为新的工程角色

当 Agent 从 Prompt 走向 Platform，对工程师的要求也会变化。

早期的 AI 应用工程师，重点可能是：

• 会调用大模型 API

• 会写 Prompt

• 会接一个 RAG

• 会封装几个 Tool

• 会做一个聊天界面

但企业级 AI Agent Platform Engineer 需要具备更完整的系统能力：

• 理解业务流程和权限边界

• 设计 Agent 协议和输入输出模型

• 设计 Context Schema 和 Evidence Model

• 设计 Runtime、Checkpoint、HITL、Trace

• 设计 Tool / Agent Registry

• 设计多租户隔离和权限中心

• 设计评测集、反例集和数据闭环

• 能把模型能力放进稳定工程系统里

这类工程师不只是“会调模型”，而是能回答：

• 模型错了怎么办？

• 上下文冲突怎么办？

• 工具失败怎么办？

• 权限变化怎么办？

• 人工审核如何接入？

• 多租户如何隔离？

• 线上 case 如何回放？

• 效果如何评测？

• 系统如何持续变好？

这些问题，才是企业 AI Agent 真正进入生产时绕不开的问题。

08｜总结：Prompt 是入口，Platform 才是护城河

Prompt Engineering 仍然重要，但它不再是企业 Agent 的全部。

在 Demo 阶段，Prompt 可以让模型“看起来更聪明”。 在生产阶段，Platform 才能让 Agent “持续稳定地工作”。

AI Agent 的演进路径大致是：

执行流程： Prompt Engineering → Context Engineering → Workflow Orchestration → Agent Runtime → AI Data Platform → Agent Platform Engineering

这条路径背后的本质变化是：

• 从一次模型调用，走向完整请求生命周期。

• 从提示词技巧，走向上下文治理。

• 从流程编排，走向运行时系统。

• 从单点能力，走向平台能力。

• 从一次性回答，走向数据闭环和持续优化。

所以，未来真正有竞争力的 AI Agent 工程能力，不是只会写一个好的 Prompt，而是能把模型、上下文、工具、权限、状态、观测、评测和数据闭环组织成一个企业级平台。Prompt 是入口。Platform 才是护城河。下一篇，我们继续讲：Context Engineering：为什么 Prompt 已经不再是 AI Agent 的核心？

感谢阅读与关注。如果文章对你有所启发，欢迎在评论区交流企业 AI Agent 落地过程中遇到的问题。