从 Prompt 到 Platform：企业级 AI Agent 平台工程专栏导读

从 Prompt 到 Platform：企业级 AI Agent 平台工程专栏导读

摘要： 当 AI Agent 从 Demo 走向企业生产，工程重点会从 Prompt 扩展到 Context、Workflow、Runtime、Graph Engineering、数据闭环、多租户治理与协议生态。本文作为十二篇专栏的总导读，梳理从 Prompt Engineering 到 Agent Platform Engineering 的技术演进路径，帮助开发者、架构师和技术负责人建立完整认知框架。

专栏关键词： AI Agent、Context Engineering、Agent Runtime、Harness Loop、LangGraph、DeepAgent、Graph Engineering、AI Data Platform、多租户、MCP、A2A、Agent Registry、Platform Engineering

本系列专栏总结了本人近年来在企业级 AI Agent 开发、落地与上线过程中的实践经验，内容涵盖 Context Engineering、Agent Runtime、数据平台、多租户治理及 Agent 工程化建设。希望这些实践总结能为正在探索企业 AI 落地的开发者和团队提供参考，感谢关注，欢迎交流与讨论。

【01】AI Agent为何从Prompt走向Platform？ 【02】Context Engineering：Prompt不再是核心 【03】Workflow为何不够？为何需要Agent Runtime？ 【04】Harness Loop：Agent 如何实现自我修正？ 【05】 企业级 Agent Runtime 如何设计？ 【06】AI Data Platform：企业AI为何需要数据中台？ 【07】多租户 AI Agent 平台设计实践 【08】MCP、A2A 与 Agent Registry 的企业实践 【09】从 LangChain 到 LangGraph，再到 DeepAgent：Agent 架构为什么不断演进？ 【10】Graph Engineering：企业级 Agent 如何从单个 Loop 走向 Graph of Graphs？ 【11】AI Agent 为什么越来越像操作系统？ 【12】Agent Platform Engineer：未来工程方向

一、为什么要写这组专栏

过去一段时间，AI Agent 的讨论经常集中在几个问题上：

• Prompt 应该怎么写？
• 应该选择哪一个大模型？
• 如何接入 RAG 和工具调用？
• LangGraph 的流程图应该怎么画？
• 多 Agent 是否一定比单 Agent 更强？

这些问题都重要，但它们主要关注模型调用和应用开发。当 Agent 真正进入企业生产环境，系统面对的问题会迅速扩大：

• 用户、组织和租户之间如何隔离？
• 模型使用的上下文来自哪里，是否可信、是否过期？
• 工具调用前如何校验权限、参数和风险？
• 长任务中断后如何恢复？
• 人工审核通过后如何继续原来的执行？
• MCP 工具和远程 Agent 如何注册、发现与治理？
• 一次失败如何回放、评测并转化为优化数据？
• 模型、Prompt、工具或策略升级后，如何证明效果真的变好？

这时，AI Agent 已经不再是“一段 Prompt 加几个工具”，而是一个包含接入、上下文、计划、执行、状态、权限、观测、评测和数据治理的复杂运行系统。

这组专栏希望回答的核心问题是：

企业如何把一个能演示的 Agent，建设成可运行、可治理、可恢复、可评测、可持续演进的平台能力？

二、专栏技术全景

十二篇文章不是十二个彼此独立的话题，而是一条逐层推进的技术主线：

可以把这条主线概括为五个阶段。

第一阶段：从模型调用转向上下文控制

Prompt Engineering 解决一次模型调用的指令表达问题，Context Engineering 则进一步管理模型本次推理能够看到什么、相信什么以及忽略什么。

对应文章：

• 第 1 篇：从 Prompt Engineering 到 Platform Engineering
• 第 2 篇：Context Engineering

第二阶段：从流程编排转向生产运行

Workflow 可以描述节点和流转，但企业生产环境还需要权限校验、状态恢复、幂等控制、人工审核、执行追踪和异常治理。Agent Runtime 正是承载这些能力的运行控制层。

对应文章：

• 第 3 篇：Workflow 与 Agent Runtime 的边界
• 第 4 篇：Harness Loop 与受控自我修正
• 第 5 篇：企业级 Agent Runtime 设计

第三阶段：从单次执行转向平台治理

Agent 上线后会产生 Trace、失败案例、人工反馈和评测样本。平台还要处理多租户隔离、能力注册、协议接入、版本治理和灰度发布。

对应文章：

• 第 6 篇：AI Data Platform
• 第 7 篇：多租户 Agent 平台
• 第 8 篇：MCP、A2A 与 Agent Registry

第四阶段：从单个 Loop 转向 Graph Engineering

当单个 Agent 开始拥有状态、循环、恢复和自主规划能力，下一步就不再是继续扩张一个超级 Agent，而是明确多个 Graph、Loop 和领域 Agent 之间的协议、状态、权限、预算与否决关系。

对应文章：

• 第 9 篇：从 LangChain、LangGraph 到 DeepAgent 的架构演进
• 第 10 篇：Graph Engineering 与 Graph of Graphs

第五阶段：从系统架构转向平台工程

当 Agent 平台开始统一管理多个 Graph、上下文、工具、状态、调度、权限和更新，它会越来越像一套面向智能任务的操作系统。这也推动 AI 工程师的能力重心发生变化。

对应文章：

• 第 11 篇：AI Agent 为什么越来越像操作系统
• 第 12 篇：AI Agent Platform Engineer

三、十二篇文章目录

四、第一篇：AI Agent 为何从 Prompt 走向 Platform

这篇是整个专栏的世界观。

Prompt Engineering 关注的是：如何让模型在一次调用中更准确地理解任务、遵循约束并输出指定格式。

但企业级 Agent 需要处理的是一条完整生命周期：

用户请求 → 身份与权限 → 上下文装配 → 计划生成 → 工具执行 → 状态保存 → 人工审核 → 结果生成 → Trace 采集 → 评测与优化

当问题扩展到这一层，仅靠延长 Prompt 已经无法解决。因为权限不能依赖模型自觉，状态恢复不能依赖对话历史，审计不能依赖最终答案，系统优化也不能依赖开发者的主观感受。

这篇文章建立三个基础判断：

建议先读原因： 后续十一篇都建立在这个判断之上。

五、第二篇：Context Engineering 为什么成为核心

模型能力不断提升后，很多 Agent 问题并不是模型不会推理，而是模型拿到的信息不完整、不可信或不适合当前任务。

Context Engineering 关注四个问题：

• 上下文来自哪些来源？
• 不同来源的可信度如何判断？
• 当前用户有权看到哪些内容？
• 在有限 Token 预算内，哪些信息应该进入本次推理？

企业 Agent 的上下文通常同时包含用户输入、会话摘要、长期记忆、RAG 知识、实时业务数据、多模态证据、权限边界和风险策略。它们不能被简单拼接成一个超长 Prompt。

真正可靠的上下文系统需要完成采集、归一、去重、冲突检测、权限过滤、时效判断、敏感信息处理和快照留存。

这篇文章还会区分四个经常被混用的概念：

• State： 当前请求的运行状态。
• Checkpoint： 中断恢复所需的持久化状态。
• Memory： 跨会话保留的稳定事实与偏好。
• RAG： 从外部知识源检索出的参考信息。

读完后的关键收获： Prompt 决定模型如何表达，而 Context Engineering 决定模型基于什么事实进行推理。

六、第三篇：Workflow 为什么不够

Workflow 擅长表达节点、条件、分支、循环和结束条件。它让 Agent 从不可控的自由调用，进入可观察、可编排的状态机。

但生产环境中的关键问题不只发生在流程图内部：

• 调用者是否有权限执行当前动作？
• 工具超时后能否安全重试？
• 重复请求如何保持幂等？
• 人工审核等待数小时后如何恢复？
• 权限在等待期间发生变化怎么办？
• 第三方系统返回部分成功时如何处理？
• 线上失败如何进入评测集？

这些问题需要统一的 Runtime 负责，而不能散落在每个 Workflow 节点里。

因此，更合理的关系是：

Workflow 是 Runtime 内部的流程表达能力，Runtime 是承载 Agent 生产运行的控制系统。

这篇文章适合已经使用 LangGraph、状态机或 DAG 编排工具，但开始遇到权限、恢复、审计和运维问题的读者。

七、第四篇：Harness Loop 如何实现受控自我修正

“Agent 能够自我反思和自我修正”听起来很有吸引力，但企业系统不能允许模型无限循环，也不能允许模型自行突破权限或修改策略。

Harness Loop 的重点不是让模型不断思考，而是为循环增加确定性约束：

• 计划是否符合结构要求？
• 参数是否完整、类型是否正确？
• 当前动作是否在权限范围内？
• 工具结果是否成功、完整且可信？
• 多个来源之间是否存在冲突？
• 当前失败是否适合重试？
• 是否已经达到循环次数、时间或成本上限？
• 是否需要澄清、降级或转人工？

一次受控循环通常包含：

上下文装配 → 计划生成 → 计划校验 → 权限校验 → 执行 → 结果观察 → 偏差分类 → 重试、重规划、澄清、人工审核或结束

这篇文章特别强调在线修正和离线优化的区别。

• 在线阶段可以重试、澄清、重新规划或进入人工审核。
• Prompt、策略、RAG、工具描述和模型版本的长期改进，应经过离线评测和灰度发布。

核心边界： Agent 可以在既定 Harness 内调整执行路径，但不能在生产环境中不受控制地重写自己的规则。

八、第五篇：企业级 Agent Runtime 如何设计

第五篇是整个专栏的架构核心。

企业级 Agent Runtime 可以理解为 AI 任务的生产控制层。它连接用户请求、上下文系统、模型、工具、远程 Agent、状态存储、人工审核、可观测系统和数据平台。

一个完整 Runtime 至少需要回答以下问题：

文章中的架构不是要求企业一开始就拆成大量微服务，而是先建立清晰责任边界。早期可以采用模块化单体，只有在团队、流量、隔离和扩缩容需求明确后再拆分服务。

核心判断： Runtime 的价值不在于让架构图更复杂，而在于把原本散落在各 Agent 中的生产共性能力集中治理。

九、第六篇：AI Data Platform 为什么不可缺少

Agent 上线并不意味着系统已经完成。恰恰相反，真实用户、真实数据和真实工具接入后，最有价值的问题才会开始出现。

AI Data Platform 负责把这些线上信号转化为可治理的数据资产：

• 哪些任务成功，哪些任务失败？
• 失败发生在检索、计划、参数、权限、执行还是回答阶段？
• 用户反馈和人工审核结果如何关联到原始 Trace？
• 哪些高频失败应该沉淀为困难样本？
• 新模型、新 Prompt 或新工具版本是否优于旧版本？
• 离线评测结果能否支持灰度发布决策？

这篇文章把数据闭环拆为四类能力：

• 采集： 保存执行事件、上下文快照、工具结果和用户反馈。
• 治理： 脱敏、去重、质量检查、版本管理和访问控制。
• 评测： 建设基准集、回归集、困难集和安全集。
• 反馈： 将评测结论转化为 Prompt、RAG、工具、策略和模型改进任务。

核心判断： 没有 Dataset 和 Evaluation，所谓“Agent 变好了”通常只是主观感受。

十、第七篇：多租户 Agent 平台如何设计

传统 SaaS 的多租户重点是数据隔离和访问控制。Agent 平台的多租户更复杂，因为租户边界还会进入模型上下文、RAG 检索、Memory、工具目录、Checkpoint、Trace 和评测数据。

一个请求即使在数据库层没有越权，也可能通过以下方式发生信息泄漏：

• 检索到了其他租户的知识片段。
• 长期记忆使用了错误的命名空间。
• Planner 看到了当前租户无权使用的工具。
• Trace 记录了未经脱敏的敏感数据。
• 公共评测集混入租户私有案例。
• 人工审核恢复时使用了已经过期的权限快照。

因此，租户上下文不能只在入口校验一次，而要贯穿请求生命周期：

身份识别 → 上下文过滤 → 能力目录裁剪 → 计划校验 → 执行前权限确认 → 状态隔离 → Trace 隔离 → 数据集治理

这篇文章还讨论模型网关、配额、区域与数据驻留、高风险动作策略，以及不同租户如何配置不同的人工审核规则。

核心判断： 多租户不是 Agent 平台外围的一层鉴权，而是贯穿所有运行与数据资产的底层安全模型。

十一、第八篇：MCP、A2A 与 Agent Registry 如何协作

MCP、A2A 和 Agent Registry 解决的是三个不同问题：

协议解决连接问题，但企业生产环境还需要回答：

• 当前租户能否使用这个工具或 Agent？
• 能力版本是否兼容？
• 调用是否需要人工审核？
• 超时、重试和降级策略是什么？
• 调用成本和配额如何控制？
• 结果如何进入 Trace 和评测？
• 能力变更如何进行回归测试和灰度发布？

所以，MCP 和 A2A 不应该绕过 Runtime 直接成为自由调用通道。更稳妥的关系是：

协议负责连接，Registry 负责治理，Runtime 负责执行。

这篇文章适合正在建设企业工具生态、多 Agent 协作或内部能力市场的团队。

十二、第九篇：从 LangChain 到 LangGraph，再到 DeepAgent

前八篇解决了 Prompt、Context、Runtime、数据、租户和协议治理问题。第九篇回到 Agent 内部，解释执行结构为什么会持续演进：

执行流程： Component Integration → Stateful Orchestration → Controlled Agent Loop

这里讨论的不是三个框架谁替代谁，而是企业 Agent 在任务复杂度持续上升后，工程对象发生了三次变化：

LangChain 主要解决模型、Prompt、Retriever 与 Tool 如何组合，让企业可以先建立稳定的能力连接层。LangGraph 进一步把 State、Node、Edge、Checkpoint 和人工中断显式建模，使 Agent 从一次模型调用升级为可观察、可暂停、可恢复的状态机。

当任务不再适合预先写死全部步骤时，Agent Harness 会在状态图之上管理动态计划、专业子 Agent、上下文裁剪、中间产物、预算以及终止条件。模型可以提出下一步计划，也可以根据执行结果重新规划，但权限、风险、循环次数和最终执行权仍由 Runtime 与确定性规则控制。

这三种能力在生产系统中通常会同时存在：

因此，第九篇不是一篇框架选型文章，而是在解释企业 Agent 为什么会从“连接组件”走向“管理状态”，再走向“控制长期执行闭环”。当平台中只有一个 Loop 时，这套结构仍可以在一个 Agent 内部完成；当多模态处理、根调度和多个领域 Agent 都拥有独立 Loop 后，架构问题就会继续升级为下一篇的 Graph Engineering。

核心判断： 框架演进不是为了扩大模型权限，而是为了让越来越复杂的任务仍然具备状态边界、恢复能力和确定性控制。

十三、第十篇：Graph Engineering 如何组织多个 Loop

当多模态处理、根调度中心和领域 Agent 都拥有自己的 Graph 后，系统会形成 Graph of Graphs。此时真正困难的，不再是某一个节点怎么写，而是：

• 父图与子图如何传递状态？
• 多个 Loop 如何共享 Evidence 和 Artifact？
• Checkpoint 如何隔离？
• 谁拥有全局预算和最终否决权？
• 失败如何局部恢复而不扩散？
• Trace 如何进入 Dataset 和离线评测？

第十篇将企业级 Graph of Graphs 拆成五个相互配合的层次：

Graph Engineering 真正要设计的，也不只是父图调用哪些子图，而是六类可以被验证的关系：

在这样的结构中，根控制图持有全局任务视角，领域子图只处理被授权的局部任务。子图可以返回结果、证据、状态和风险信号，但不能自行扩大权限，也不能绕过全局预算和执行策略。局部 Loop 失败时，系统优先局部恢复；只有影响全局目标或安全边界时，才升级到重新规划、人工审核或终止任务。

多个 LangGraph 连接在一起并不自动等于 Graph Engineering。如果图与图之间仍然依赖自由文本传递，没有稳定输入输出协议、Checkpoint 隔离、权限治理、跨图 Trace 和评测闭环，那么它们仍然只是多个独立 Agent 应用，而不是一个可长期运行的平台系统。

核心判断： Multi-Agent 说明系统里有多个 Agent，Graph Engineering 说明这些 Agent 之间的关系被显式设计和治理。

十四、第十一篇：AI Agent 为什么越来越像操作系统

当 Agent Platform 开始管理模型、上下文、工具、状态、任务、权限、隔离、审计和版本更新，它会呈现出类似操作系统的结构。

这个类比的意义，不是创造一个新的营销名词，而是帮助团队重新理解模型的位置：

模型更像被运行环境调度的推理单元，而不是整个系统本身。

文章同时提醒：企业不应该建设一个拥有全部权限、全部工具和全部知识的“超级 Agent”。更合理的方式是建设统一运行底座，再通过边界清晰的专业 Agent 承担不同任务。

十五、第十二篇：Agent Platform Engineer 的能力模型

最后一篇把前十一篇的架构问题落到工程师能力上。

AI Agent Platform Engineer 不是只会调用模型 API 的应用开发者，也不是只负责训练模型的算法工程师。这个角色更接近 AI 时代的平台工程师，需要同时理解：

• 模型调用、结构化输出和工具调用；
• Context、RAG、Memory 和多模态证据；
• Workflow、Runtime、Harness Loop 和状态恢复；
• 权限、租户、安全、审计和风险控制；
• Trace、Dataset、Evaluation 和反馈闭环；
• MCP、A2A、Registry 和模型网关；
• API、异步任务、消息系统、存储与可观测性。

文章给出的成长方向不是“把所有框架都学一遍”，而是围绕一条真实生产链路建立系统能力：

核心判断： 未来 AI 工程师的重要差异，不只是会不会调用模型，而是能不能把不确定的模型能力放进确定的工程系统。

十六、三条推荐阅读路线

路线一：Agent 应用工程师

推荐顺序：

01 → 02 → 03 → 04 → 05 → 09 → 10 → 06

这条路线先建立平台视角，再依次理解上下文、运行时、自我修正、Graph Engineering 和数据闭环。适合已经做过 RAG、工具调用或 LangGraph 应用，希望向生产工程深入的读者。

路线二：企业架构师与技术负责人

推荐顺序：

01 → 05 → 07 → 08 → 09 → 10 → 11 → 06

这条路线重点关注总体架构、多租户、协议治理、平台边界和持续演进。适合负责企业 AI 技术路线、平台选型或跨团队协作的读者。

路线三：准备转向 AI 平台工程的后端工程师

推荐顺序：

03 → 05 → 02 → 04 → 06 → 07 → 08 → 09 → 10 → 11 → 12

后端工程师通常已经具备 API、存储、异步任务和可观测性基础，可以先从 Runtime 切入，再补齐上下文、评测、多租户和协议生态。

十七、十二篇文章共同回答了什么

如果把十二篇内容压缩成一套企业 Agent 平台方法论，可以归纳为三个闭环。

1. 运行控制闭环

请求 → 上下文 → 计划 → 校验 → 执行 → 观察 → 修正 → 结果

这个闭环解决“Agent 如何安全、稳定地完成一次任务”。

2. 状态与治理闭环

身份 → 租户 → 权限 → Registry → Checkpoint → Audit → 人工审核

这个闭环解决“任务如何在组织边界和风险约束下运行”。

3. 数据演进闭环

Trace → Sample → Dataset → Evaluation → 改进 → 灰度 → 新 Trace

这个闭环解决“系统如何证明自己在持续变好”。

只有三个闭环同时成立，Agent 才能从一次性 Demo 走向企业平台能力。

十八、专栏的十二个核心判断

十九、结语

AI Agent 的早期创新主要来自模型能力、Prompt 技巧和工具调用。进入企业生产阶段后，竞争重点会逐渐转向上下文质量、运行稳定性、安全治理、数据闭环和平台复用。

这也是专栏标题“从 Prompt 到 Platform”的真正含义：

不是 Prompt 不再重要，而是企业需要在 Prompt 之外，建设一套能够承载模型不确定性的确定性工程系统。

模型会继续升级，框架会不断变化，协议也会持续演进。但身份、权限、上下文、状态、执行、审计、评测和数据治理这些问题不会消失。

真正具备长期价值的能力，不是记住某一个框架的 API，而是理解这些问题为什么存在，并能够设计出边界清晰、可以验证、能够演进的平台系统。

推荐 CSDN 标签：

AI Agent 大模型 Agent Runtime Context Engineering Platform Engineering