【12】Agent Platform Engineer：未来工程方向

第一篇讲了为什么 AI Agent 会从 Prompt Engineering 演进到 Platform Engineering。第二篇讲了 Context Engineering，说明 Prompt 已经不再是 Agent 的唯一核心。第三篇讲了 Workflow 为什么不够，企业为什么需要 Agent Runtime。

第四篇讲了 Harness Loop，解释 Agent 如何从执行走向自我修正。第五篇讲了企业级 Agent Runtime 的设计。第六篇讲了 AI Data Platform，说明企业 AI 为什么需要数据中台。第七篇讲了多租户 Agent 平台。第八篇讲了 MCP、A2A 和 Agent Registry。

第十一篇讲了 AI Agent 为什么越来越像操作系统。

写到这里，其实会自然推导出一个新的工程岗位：

AI Agent Platform Engineer
AI Agent 平台工程师

这个岗位不是简单的 Prompt 工程师。也不是传统意义上的算法工程师。也不完全等同于后端工程师、平台工程师、数据工程师或 MLOps 工程师。

它更像是一个交叉岗位：

理解模型能力，
理解企业 SaaS，
理解后端架构，
理解运行时系统，
理解上下文工程，
理解工具治理，
理解评测闭环，
理解多租户和权限边界。

未来几年，很多企业不一定会直接把岗位写成 “AI Agent Platform Engineer”。但实际工作内容会越来越接近它。这篇文章就作为整个专栏的收束篇，专门讲这个方向。

01｜岗位定义与出现背景

我对 AI Agent Platform Engineer 的定义是：

关键判断： 负责把大模型能力工程化为企业可用 Agent 平台的工程师。

这句话里有几个关键词。第一，是“大模型能力”。他需要理解模型能做什么，也要理解模型不能稳定做什么。第二，是“工程化”。他不是只做 Demo，而是要把 AI 能力放到真实系统里运行。第三，是“企业可用”。

企业可用意味着：

可治理。
可追踪。
可恢复。
可评测。
可灰度。
可审计。
可多租户。
可持续优化。

第四，是“平台”。平台意味着能力不是一次性写死在某个业务功能里，而是可以被多个场景复用、扩展和治理。所以，这个岗位的核心不是“会调模型 API”。

而是：

关键判断： 把模型、上下文、工具、权限、状态、数据和评测组织成一个稳定的生产系统。

为什么会出现这个岗位？

早期 AI 应用比较简单。

一个典型结构是：

执行流程： 用户输入 → Prompt → LLM → 输出

这时工程重点在 Prompt、模型选择和基础接口。

但企业开始做 Agent 之后，架构会变成：

执行流程： 用户输入 → 租户上下文 → 权限过滤 → 上下文装配 → Agent Runtime → 计划生成 → 校验机制 → Tool / Agent Registry → 执行层 → Checkpoint → Trace → 数据平台 → 评测

这已经不是单点 AI 能力。这是一个复杂运行系统。

它会涉及：

多租户隔离
用户权限
角色权限
上下文装配
知识检索
工具调用
任务调度
异步执行
人工确认
失败恢复
链路追踪
数据沉淀
离线评测
版本灰度
成本控制

传统岗位很难完全覆盖这件事。算法工程师擅长模型训练、特征、评估和算法优化。后端工程师擅长服务、接口、数据库、事务和系统稳定性。数据工程师擅长数据采集、清洗、建模、仓储和数据链路。平台工程师擅长基础设施、组件化、工具链和开发效率。MLOps 工程师擅长模型部署、实验管理、模型版本和训练推理流水线。但 Agent 平台需要把这些能力组合起来。

它既要懂模型，也要懂系统。既要懂业务流程，也要懂平台治理。既要会构建在线 Runtime，也要会构建离线数据闭环。这就是 AI Agent Platform Engineer 出现的原因。

02｜它和现有工程岗位有什么区别

Prompt Engineer 关注的是：

如何设计指令。
如何约束模型行为。
如何提升输出质量。
如何设计 Few-shot。
如何让模型按格式回答。

这些能力仍然重要。

但 AI Agent Platform Engineer 关注的是更大的系统边界：

Prompt 从哪里来？
Prompt 如何版本管理？
上下文如何进入 Prompt？
哪些上下文不能进入 Prompt？
模型输出如何被结构化校验？
工具调用如何被授权？
失败样本如何进入评测？
Prompt 改动如何灰度？
线上效果如何对比？

Prompt Engineer 更像“写好模型指令的人”。AI Agent Platform Engineer 更像“建设模型运行环境的人”。

一个简单对比是：

Prompt Engineer 解决一次调用的质量问题。
AI Agent Platform Engineer 解决长期运行的系统问题。

如果只会写 Prompt，很难处理：

多租户隔离
权限回收
工具风险
中断恢复
Trace 复盘
评测回归
版本灰度
数据闭环

所以，Prompt 是起点。Platform 才是企业落地的主战场。

它和算法工程师有什么区别？

算法工程师通常更关注：

模型结构
训练数据
损失函数
评估指标
微调方法
推理性能
模型压缩
实验对比

AI Agent Platform Engineer 不一定负责训练基础模型。

他更关注：

模型如何进入业务系统。
模型输出如何变成可执行计划。
模型调用如何被 Runtime 调度。
模型失败如何被发现和修正。
模型效果如何被线上数据持续评估。

也就是说，算法工程师更接近模型能力本身。AI Agent Platform Engineer 更接近模型能力的生产化落地。当然，两者不是割裂的。

一个优秀的 Agent 平台工程师，至少要理解：

不同模型能力边界。
结构化输出的稳定性。
RAG 与长上下文的取舍。
评测集和指标设计。
推理延迟和成本。
模型版本变化带来的行为漂移。

但他的主战场通常不是训练模型，而是建设：

可运行、可观测、可治理、可迭代的 AI 系统。

它和后端工程师有什么区别？

AI Agent Platform Engineer 很大程度上需要扎实后端能力。因为 Agent 平台最终仍然是企业系统的一部分。

它需要：

API 设计
数据库设计
缓存
消息队列
异步任务
权限系统
服务治理
日志追踪
配置管理
灰度发布
异常处理

但它比普通后端多了一层模型不确定性。传统后端函数通常是确定性的。输入相同，输出大体可预期。Agent 系统不同。

它会遇到：

模型输出不稳定。
模型计划可能偏离目标。
检索结果可能不完整。
工具返回结果可能冲突。
上下文可能过长。
模型可能误解工具语义。
用户输入可能带有干扰。

所以，AI Agent Platform Engineer 需要在后端能力之上，增加一套 AI 原生控制机制：

结构化输出协议
计划校验机制
执行前权限校验
Tool Schema
Context Snapshot
Checkpoint
Harness Loop
Evaluation Dataset
Failure Classification
Prompt Versioning

普通后端工程师关注“服务是否按代码逻辑运行”。Agent 平台工程师还要关注“模型行为是否在平台可控范围内运行”。这是核心差异。

它和 MLOps 工程师有什么区别？

MLOps 关注模型从训练到部署的生命周期。

典型能力包括：

数据集管理
训练流水线
实验管理
模型注册
模型部署
模型监控
模型回滚
推理服务

这些能力对 AI 系统很重要。但 Agent 平台还要处理更复杂的运行链路。Agent 的质量不只由模型决定。

还由以下因素共同决定：

Prompt 版本
Context 组装策略
知识检索结果
工具描述
工具权限
Planner 策略
计划校验规则
Runtime 状态
用户反馈
业务策略

所以 Agent Platform 的 MLOps 不只是“模型版本管理”。

它还要管理：

Prompt 版本
Agent 版本
Tool 版本
Knowledge 版本
Policy 版本
Evaluation 版本
Trace 数据
Failure Case 数据

这也是为什么我更愿意把这个岗位叫作 AI Agent Platform Engineer，而不是简单归入 MLOps。它覆盖的是模型之上的智能运行时系统。

图｜AI Agent Platform Engineer 的能力结构

03｜这个岗位每天在做什么？

如果把 AI Agent Platform Engineer 的日常工作拆开，大概会有几类。

建设 Agent Runtime

他要设计 Agent 如何运行。

包括：

任务生命周期
状态机
执行节点
工具调用
Agent 调用
失败重试
中断恢复
人工确认
结果聚合

他需要回答：

一个任务从开始到结束经过哪些阶段？
每个阶段输入输出是什么？
每一步如何记录状态？
失败后从哪里恢复？
哪些动作需要暂停确认？
哪些结果可以直接返回？

这不是简单画一个流程图。这是设计一个可运行、可恢复、可追踪的 Runtime。

建设 Context Engineering 链路

他要设计上下文如何进入模型。

包括：

用户输入
会话摘要
长期偏好
租户配置
角色权限
知识片段
工具结果
任务状态
风险提示
输出约束

他需要回答：

哪些上下文可以进 Prompt？
哪些上下文只供代码侧使用？
哪些上下文需要脱敏？
哪些上下文需要摘要？
哪些上下文需要引用溯源？
如何控制 token 预算？
如何避免旧上下文污染当前任务？

Context Engineering 是 Agent 平台的核心能力之一。它决定模型看到什么。模型看到什么，很大程度上决定模型会做什么。

建设 Tool 和 Agent Registry

他要管理平台有哪些能力。

包括：

工具注册
Agent 注册
能力描述
输入输出 schema
版本管理
权限要求
风险等级
租户策略
调用限制
审计要求

他需要回答：

当前任务能看到哪些工具？
当前用户能调用哪些 Agent？
哪些能力需要人工确认？
哪些能力只能内部调用？
哪些能力处于灰度状态？
哪些能力已经下线？

Registry 的价值不是列清单。它是 Runtime 做能力发现、权限过滤和版本治理的基础。

建设权限与安全策略

Agent 平台越强，越要重视权限。

AI Agent Platform Engineer 要设计：

租户权限
用户权限
角色权限
数据权限
工具权限
Agent 权限
任务级权限
风险策略
审计策略

他需要坚持一个原则：

关键判断： 模型可以提出计划，但不能成为最终权限裁决者。

权限应该由平台代码、策略引擎和实时状态决定。不能只靠 Prompt 约束。

建设 Trace、Evaluation 和数据闭环

他要让 Agent 系统可以被复盘和优化。

包括：

记录用户问题
记录上下文版本
记录模型计划
记录工具调用
记录权限校验
记录失败原因
记录最终结果
记录用户反馈
沉淀评测样本
构建反例集
做版本对比
做回归评测

这决定系统能不能持续变好。如果没有数据闭环，Agent 系统上线后只能靠人工感觉调 Prompt。

有了数据闭环，平台才能进入：

关键判断： 运行 → 追踪 → 评测 → 失败分类 → 样本沉淀 → 版本优化 → 回归验证 → 灰度发布

这才是企业级 AI 的长期竞争力。

04｜七层能力模型

我会把 AI Agent Platform Engineer 的能力模型分成七层。

第一层：AI 基础能力。
第二层：后端工程能力。
第三层：Agent Runtime 能力。
第四层：Context Engineering 能力。
第五层：数据与评测能力。
第六层：平台治理能力。
第七层：业务抽象能力。

这七层不是并列堆概念，而是逐层支撑。

第一层：AI 基础能力

AI 基础能力不是指一定要能训练大模型。而是要理解大模型在工程里的基本行为。

至少包括：

Prompt 设计
System Prompt
Few-shot
结构化输出
函数调用
工具调用
Embedding
RAG
长上下文
多轮对话
模型幻觉
模型延迟
Token 成本
模型版本差异

这里最重要的是理解模型边界。

一个成熟工程师不能只说：

模型不稳定。
模型会幻觉。
Prompt 要优化。

他应该能进一步说清楚：

不稳定发生在哪个步骤？
是意图理解不稳定，还是工具选择不稳定？
是检索召回问题，还是上下文拼接问题？
是输出格式问题，还是业务判断问题？
是模型本身问题，还是平台约束不足？

这就是从“会用 AI”到“会工程化 AI”的差异。

第二层：后端工程能力

Agent 平台最终要运行在真实服务里。所以后端能力是基础。

至少需要：

API 设计
认证授权
数据库建模
事务边界
缓存设计
消息队列
异步任务
任务调度
幂等控制
错误处理
日志追踪
配置中心
灰度发布
性能优化

很多 AI Demo 做不成企业系统，不是因为模型不好，而是因为后端工程能力不足。

比如：

没有幂等设计，工具重试会重复执行。
没有超时控制，任务会长时间挂起。
没有状态持久化，刷新后任务丢失。
没有权限过滤，模型能看到不该看到的能力。
没有审计日志，出了问题无法复盘。
没有版本管理，Prompt 改动无法回滚。

Agent Platform Engineer 必须把 AI 能力放回工程系统里看。

第三层：Agent Runtime 能力

Agent Runtime 是这个岗位的核心区。

它需要理解：

任务状态机
Plan / Act / Observe 循环
工具执行
多 Agent 协作
Human-in-the-loop
Checkpoint
Resume
Retry
Timeout
Cancel
Fallback
Result Aggregation

一个成熟 Runtime 不是让模型无限自由行动。而是让模型在受控框架内完成任务。

关键问题包括：

模型什么时候只负责理解？
模型什么时候可以生成计划？
计划由谁校验？
工具由谁执行？
高风险动作由谁确认？
失败后由谁决定重试？
恢复时如何保证上下文一致？

如果这些问题没有平台答案，就会全部落到 Prompt 里。

最后系统会变成：

Prompt 负责规划。
Prompt 负责权限。
Prompt 负责异常。
Prompt 负责格式。
Prompt 负责业务规则。
Prompt 负责风险控制。

这不是工程化。这是把平台职责压给模型。

第四层：Context Engineering 能力

Context Engineering 是未来 AI 工程师必须补上的能力。

过去很多人把上下文理解成：

把历史消息拼进去。
把知识库结果拼进去。
把工具说明拼进去。

这只是最初级做法。

企业级 Context Engineering 要考虑：

上下文来源
上下文可信度
上下文时效性
上下文权限
上下文压缩
上下文摘要
上下文引用
上下文污染
上下文版本
上下文预算

一个很重要的原则是：

关键判断： 不是所有对系统有用的信息，都应该给模型看。

有些信息应该给模型看，有些信息只应该由校验机制处理，有些信息只应该进入执行前权限校验、Trace 或检索候选。这就是 Context Engineering 和 Prompt 拼接的区别。

第五层：数据与评测能力

企业 AI 不能只靠主观体验判断好坏。AI Agent Platform Engineer 必须具备评测意识。

至少要能设计：

任务成功率
结构化输出成功率
工具选择准确率
权限拦截准确率
知识召回质量
回答一致性
人工介入率
失败分类
用户反馈采集
版本对比实验
回归评测集

更重要的是，他要知道指标必须有定义。

不能随便写：

准确率提升 30%。
响应速度提升 50%。
效果显著提升。
成本大幅下降。

这些说法如果没有：

数据集定义
样本数量
基线版本
统计口径
评测方法
硬件环境
置信范围

就很难经得起追问。

真正成熟的表达应该是：

在某类任务评测集上，
以某个版本作为 baseline，
采用某个指标，
在某个样本规模下，
得到某个可解释结果。

这就是工程化 AI 和宣传式 AI 的区别。

第六层：平台治理能力

Agent 平台不是给一个人用的脚本。它服务的是企业组织。所以要有平台治理能力。

包括：

多租户隔离
角色权限
能力注册
版本管理
配置管理
灰度发布
审计追踪
成本配额
风险策略
数据合规

这些能力看起来不如模型炫。但它们决定系统能不能进入生产。企业不缺 Demo。

企业缺的是：

能上线。
能控风险。
能查问题。
能管版本。
能隔离租户。
能持续优化。

AI Agent Platform Engineer 的价值，恰恰在这里。

第七层：业务抽象能力

最后一层是业务抽象。Agent 平台不是纯技术玩具。它必须服务真实业务场景。但工程师不能把每个场景都写成一次性逻辑。

他要能抽象出：

任务类型
能力类型
工具类型
上下文类型
风险类型
审批类型
数据类型
评测类型

例如在通用企业 SaaS 里，很多场景可以抽象为：

查询类任务
解释类任务
生成类任务
诊断类任务
配置类任务
协同类任务
审核类任务
分析类任务

每类任务对应不同 Runtime 策略：

查询类任务更重视权限过滤和引用来源。
解释类任务更重视上下文完整性和表达一致性。
生成类任务更重视格式校验和版本管理。
诊断类任务更重视证据链和失败分类。
配置类任务更重视风险策略和人工确认。
协同类任务更重视状态跟踪和异步恢复。
审核类任务更重视规则、审计和可复盘。
分析类任务更重视数据来源和指标口径。

这就是业务抽象能力。它决定平台能不能从一个场景扩展到多个场景。

一个能力地图

可以用下面这张图理解 AI Agent Platform Engineer 的能力结构：

图｜AI Agent Platform Engineer 能力地图

这张图里，AI 只是其中一部分。真正的难点是把这些能力合成一个平台。

05｜从功能开发到平台建设的成长路径

AI Agent Platform Engineer 可以按三个阶段成长。

初级阶段：会用模型做功能。
中级阶段：会把 Agent 放进系统。
高级阶段：会建设 Agent 平台。

每个阶段的关注点不一样。

初级阶段：会用模型做功能

这个阶段的目标是能完成明确 AI 功能。

需要掌握：

模型 API 调用
Prompt 设计
结构化输出
基础 RAG
基础工具调用
简单对话状态
基础异常处理

可以做的项目包括：

智能问答助手
文档摘要工具
知识库检索问答
表单生成助手
报告生成助手
简单工具调用 Agent

这个阶段最常见的问题是：

只关心回答效果，不关心系统边界。
只做单轮 Demo，不做状态管理。
只拼 Prompt，不做上下文治理。
只看主观体验，不做评测集。

要进入下一阶段，必须开始理解：

关键判断： AI 功能不是一次调用，而是系统链路的一部分。

中级阶段：会把 Agent 放进系统

这个阶段的目标是能做生产级 AI 应用。

需要掌握：

后端服务设计
用户身份和权限
租户上下文
工具 schema
任务状态
异步执行
Trace
错误分类
Prompt 版本
基础评测

可以做的项目包括：

企业知识问答平台
智能文档处理系统
业务流程协同助手
数据分析问答助手
配置诊断助手
内部运营 Agent

这个阶段的关键变化是：

关键判断： 从“模型回答得好不好”，转向“系统运行得稳不稳”。

你要开始能回答：

为什么这次 Agent 调错工具？
为什么某个用户看到了不该看的知识？
为什么同一个问题不同版本回答不一致？
为什么任务中断后无法恢复？
为什么线上问题无法复盘？
为什么评测结果和用户体验不一致？

能回答这些问题，才真正进入 AI 工程化。

高级阶段：会建设 Agent 平台

高级阶段的目标是建设可复用平台，而不是单个 AI 功能。

需要掌握：

Agent Runtime 设计
上下文管理
Tool Registry
Agent Registry
执行前权限校验
Policy Engine
Checkpoint Store
Trace Pipeline
Evaluation Platform
Multi-tenant Architecture
AI Data Platform
Version Governance

这个阶段要解决的问题是：

如何让多个业务场景复用同一套 Runtime？
如何让工具和 Agent 可注册、可治理、可灰度？
如何让不同租户拥有不同能力边界？
如何让线上 Trace 进入评测和优化闭环？
如何让 Prompt、工具、知识、策略、模型版本可追踪？
如何让平台在风险可控前提下扩展能力？

高级 Agent 平台工程师的价值，不是写出一个很复杂的 Agent。而是让企业可以持续、安全、低成本地生产 Agent 能力。

06｜简历、作品集与面试表达

如果你想往这个方向发展，简历和作品集不能只写：

熟悉大模型。
熟悉 Prompt。
熟悉 RAG。
熟悉 Agent。
熟悉工具调用。

这些太泛。应该写成平台能力。

例如：

关键判断： 建设企业级知识检索与问答平台，支持文档解析、索引构建、权限过滤、引用溯源、问答评测和版本管理。

或者：

关键判断： 设计 Agent Runtime 执行链路，围绕任务状态、执行计划、权限校验、工具调用、人工确认、失败恢复和 Trace 采集进行工程化封装。

或者：

关键判断： 建设 AI 数据闭环，将线上问题、上下文快照、执行链路、失败原因和用户反馈沉淀为评测集、反例集和版本回归样本。

这种表达比“做了一个 AI 助手”更有工程含金量。

一个更好的项目组合

如果要用项目证明能力，我建议不要堆很多小 Demo。更好的方式是准备三类项目。

项目一：企业知识与 RAG 平台

证明你理解知识工程。

重点体现：

文档解析
切分策略
向量检索
混合检索
重排
引用溯源
权限过滤
知识版本
问答评测
召回失败分析

这个项目回答的是：

模型如何可靠使用企业知识？

项目二：企业智能交互与上下文平台

证明你理解多输入、多上下文和结构化理解。

重点体现：

多渠道输入
上下文合并
实体抽取
结构化输出
敏感信息处理
上下文快照
任务意图识别
人机协同入口

这个项目回答的是：

用户复杂输入如何变成可执行上下文？

项目三：企业 Agent Runtime 与数据闭环平台

证明你理解 Agent Platform。

重点体现：

Agent Runtime
任务状态机
执行计划
工具调用
权限校验
人工确认
失败恢复
Trace
评测集
反例集
版本回归
数据回灌

这个项目回答的是：

Agent 如何在企业系统里长期稳定运行？

这三个项目组合起来，比十几个零散 Demo 更有说服力。

因为它们覆盖了：

知识层
上下文层
运行时层
数据闭环层
平台治理层

这就是 AI Agent Platform Engineer 的完整叙事。

面试时应该怎么讲？

如果面试官问：

你做的 Agent 项目有什么难点？

不要只回答：

Prompt 难调。
模型有幻觉。
RAG 召回不准。
工具调用不稳定。

这些回答太常见。

更好的回答是：

难点不只是模型效果，而是 Agent 进入企业系统后的可控运行问题。
我们需要解决上下文组装、权限过滤、工具治理、状态持久化、人工确认、Trace 复盘和评测闭环。

如果面试官继续问：

那你具体怎么做？

可以按链路讲：

入口层先识别租户、用户和任务类型。
上下文管理根据权限和 token 预算组装信息。
Runtime 生成结构化执行计划。
校验机制检查计划和参数。
执行前权限校验工具权限和风险策略。
执行层调用工具并记录结果。
Checkpoint 保存中间状态，支持中断恢复。
Trace 记录完整链路，进入评测和失败样本沉淀。

这比单纯说“用了某个框架”更能体现工程能力。

面试官真正想听什么？

面试官通常不只是想听你用了什么技术。

他更想判断：

你是否理解模型不确定性。
你是否理解企业系统边界。
你是否能把 Demo 变成平台。
你是否能处理权限和风险。
你是否有数据评测意识。
你是否能定位线上问题。
你是否能做长期演进。

所以回答 Agent 项目时，要尽量避免“技术名词堆叠”。

不要只说：

关键判断： 我用了 RAG、Agent、Workflow、MCP、A2A、评测、向量数据库。

要说清楚：

每个模块解决什么问题。
模块之间如何连接。
系统边界在哪里。
哪些是已经实现的。
哪些是规划中的。
效果如何验证。
失败如何处理。

这才是平台工程表达。

07｜五个最容易犯的错误

想往 AI Agent Platform Engineer 方向发展，有几个常见错误要避开。

错误一：只追热点框架

很多人学习 Agent，会不断追新框架。今天学一个工作流框架。明天学一个多 Agent 框架。后天学一个工具协议。这些框架可以学。但不能只停留在框架 API。

真正要理解的是：

状态怎么管理？
上下文怎么传递？
工具怎么治理？
权限怎么裁决？
失败怎么恢复？
Trace 怎么记录？
评测怎么回归？

框架会变。这些工程问题不会变。

错误二：把 Demo 当生产系统

Demo 可以快速验证想法。

但生产系统需要更多东西：

认证授权
租户隔离
超时控制
重试策略
幂等设计
审计日志
异常降级
版本管理
灰度策略
成本控制
数据合规

很多 AI 项目失败，不是因为 Demo 不好看。而是因为 Demo 后面没有工程承接。AI Agent Platform Engineer 的价值，就是补上这部分。

错误三：没有评测意识

没有评测，Agent 项目很难持续迭代。

因为每次改动都只能靠人工感觉判断：

好像更好了。
好像更稳了。
好像更聪明了。

这不够。

至少要有：

固定评测集
反例集
任务成功标准
结构化输出校验
工具选择校验
权限校验用例
版本对比
回归报告

尤其是企业 Agent，很多问题不是回答错一句话，而是执行链路出错。所以评测不能只评最终答案。

还要评：

有没有找对知识。
有没有选对工具。
有没有越过权限。
有没有生成错误计划。
有没有在高风险动作前暂停。
有没有留下可复盘 Trace。

错误四：忽视多租户和权限

很多 Demo 默认只有一个用户。但企业 SaaS 默认是多租户、多角色、多权限。如果 Agent 平台没有多租户和权限设计，后面会非常难补。

你必须从一开始就考虑：

租户标识如何贯穿链路？
用户标识如何进入权限判断？
role 如何影响工具可见性？
知识检索如何做权限过滤？
Trace 如何按租户隔离？
Checkpoint 如何按租户隔离？
评测数据如何避免混租？

这些问题不解决，Agent 平台越强，风险越高。

错误五：夸大指标和效果

AI 项目很容易写出夸张指标。

例如：

准确率提升 80%。
成本降低 60%。
响应速度提升 10 倍。
人工效率提升 90%。

如果没有清晰口径，这些指标经不起追问。

更稳妥的做法是：

说明评测数据集。
说明样本规模。
说明 baseline。
说明指标定义。
说明测试环境。
说明统计范围。
说明是否线上验证。

AI Agent Platform Engineer 要有工程可信度。可信度比夸张更重要。

08｜一个六个月学习路线

如果想系统进入这个方向，可以按六个月推进。

第一个月：打牢 AI 应用基础

重点学习：

模型 API
Prompt 设计
结构化输出
函数调用
Embedding
基础 RAG

产出一个小项目：

支持知识检索、引用来源和结构化输出的问答系统。

重点不是炫技，而是把输入、检索、Prompt、输出校验跑通。

第二个月：补后端工程和服务化

重点学习：

API 服务
数据库
缓存
异步任务
日志
认证授权
错误处理

把第一个项目服务化。

加入：

用户身份
权限过滤
请求日志
错误分类
Prompt 版本
基础评测脚本

目标是从脚本变成服务。

第三个月：建设 Context Engineering

重点学习：

上下文来源分层
摘要策略
token 预算
知识召回
权限过滤
上下文快照

产出：

上下文管理能力。

它要能明确管理：

哪些内容进入模型。
哪些内容只供系统使用。
哪些内容需要脱敏。
哪些内容需要引用溯源。

第四个月：建设 Agent Runtime

重点学习：

任务状态机
工具调用
结构化计划
校验机制
执行前权限校验
Checkpoint
Human-in-the-loop

产出：

关键判断： 一个支持多步骤任务、工具调用、暂停确认和失败恢复的 Agent Runtime。

这个阶段要重点训练系统设计能力。不要只追求模型自动化。要追求执行可控。

第五个月：建设 Trace 和评测闭环

重点学习：

Trace 采集
失败分类
评测集
反例集
版本对比
回归测试

产出：

线上执行链路沉淀为评测样本的闭环。

目标是每次 Agent 失败都能沉淀为可复盘、可评测、可优化的数据。

第六个月：平台化和作品集整理

重点学习：

Tool Registry
Agent Registry
多租户隔离
灰度发布
成本控制
审计追踪
平台文档

最终产出：

一个企业 Agent Platform 原型。
一份架构文档。
一份评测报告。
一份项目复盘。
一份简历项目描述。

这样形成的作品集，比单个聊天 Demo 强很多。

09｜岗位分化与未来方向

未来 AI Agent Platform Engineer 可能会继续分化。大致会出现几类方向。

Agent Runtime Engineer

专注 Agent 运行时。

关注：

任务调度
状态机
工具执行
中断恢复
并发控制
运行稳定性

Context Engineer

专注上下文工程。

关注：

RAG
长期记忆
上下文压缩
知识权限
上下文污染
上下文评测

AI Data Platform Engineer

专注数据与评测闭环。

关注：

Trace
Dataset
Evaluation
Failure Case
Feedback
Version Comparison
Regression

Agent Governance Engineer

专注治理和安全。

关注：

多租户
权限
策略
审计
合规
风险控制
能力注册

AI Product Platform Engineer

专注 AI 能力产品化。

关注：

平台能力抽象
业务场景接入
用户体验
配置后台
运营工具
效果看板

这些方向未来可能会在大团队里拆开。但在中小团队里，一个人往往需要覆盖其中多块。

为什么这是未来 AI 工程师的重要方向？

原因很简单：

模型能力会越来越通用。
企业差异会越来越体现在平台工程上。

当所有人都能调用强模型时，差异不再只是模型本身。

差异会来自：

谁的上下文更准确。
谁的工具治理更好。
谁的权限体系更稳。
谁的 Runtime 更可靠。
谁的评测闭环更完整。
谁的数据沉淀更扎实。
谁能更快把失败转化为优化。

这就是平台工程的价值。

未来 AI 应用不会停留在：

一个聊天框。
一个 Prompt。
一个工具调用。
一个知识库。

它会进入：

企业流程。
企业知识。
企业数据。
企业权限。
企业协作。
企业治理。
企业运营。

进入这些地方之后，单纯会用模型已经不够。需要有人建设 AI 的工程底座。这就是 AI Agent Platform Engineer。

10｜最后：AI 工程师的能力重心正在变化

过去几年，很多人理解 AI 工程师，可能会想到：

训练模型。
调参。
写 Prompt。
接 API。
做一个智能助手。

这些仍然是重要能力。

但未来的 AI 工程师，尤其是企业方向，会越来越接近：

AI + 后端系统
AI + 平台工程
AI + 数据工程
AI + 权限治理
AI + 可观测性
AI + 评测体系
AI + 产品抽象

AI Agent Platform Engineer 的价值，不在于把概念讲得多炫。

而在于能回答：

这个 Agent 如何运行？
如何知道它运行对了？
如何知道它运行错了？
错了如何恢复？
恢复后如何评测？
评测后如何优化？
优化后如何灰度？
灰度后如何继续观测？

这是一套完整工程闭环。

如果用一句话总结整个专栏，我会这样说：

关键判断： AI Agent 的竞争，正在从模型调用竞争，转向平台工程竞争。

而 AI Agent Platform Engineer，正是这个变化里最值得关注的工程方向之一。

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

AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

别让你的 Agent 一口吃成胖子：AI Agent 任务拆分的工程实践指南

AI Agent技术社区

AI Agent律师行业智能体的实践步骤

AI Agent技术社区

MCP + 企业IM架构：AI Agent调用OA、ERP、MES时，身份和权限如何传递？

<think>我们只需要根据内容生成摘要，不超过150字。先理解文章核心：MCP+企业IM架构，AI Agent调用OA/ERP/MES时身份和权限传递。要点：IM从消息入口变任务入口；MCP解决连接，但不解决权限；需要五层身份映射；权限分层（可见性、调用、数据范围、确认）；建议组合MCP+API网关。摘要需简洁。参考生成： "本文探讨MCP与企业IM集成中AI Agent调用业务系统时的身份权