为什么我开始研究 Agent Platform Engineering

从一次企业 AI 平台实践，看 Agent 工程化演进

2024年末，DeepSeek-V3 开源模型横空出世，像一颗炸弹一样，让全国各企业事业单位都争相私有化部署自己的 LLM。也是从那时起，更多人开始觉得，AI普及的拐点或许真的到了。我突然感觉到，或许程序员在 AI 时代还有出路可走。

从模型部署，到企业 AI 能力中心

最初面对的问题很现实：如何让企业内部快速拥有一个安全、可控、可使用的大模型能力。

模型能跑起来，距离真正的业务使用还有很远的距离。企业级AI不是简单接入一个模型接口，它需要解决：

• 模型如何管理
• 检索增强（RAG）如何接入
• 应用如何构建
• 能力如何复用
• 如何提供统一入口

当时手上的算力是3台 8×32G V100 显卡机器。最初也想过部署满血版模型，但为了尽快拥有可用的模型算力，我们优先在一台机器上部署了70B的DeepSeek。2025年2月，在搜集了大量资料和技术趋势之后，我们把探索方向定在了建设企业内部AI能力中心。

为什么选择 Dify

我们选择了Dify作为基础平台，原因很直接：它最适合探索阶段的验证需求。

对于刚开始建设企业AI能力的团队，最大的挑战不是技术实现，而是不确定性。我们需要验证：

• 大模型是否真的能解决业务问题？
• 如何能快速落地？
• 业务团队如何参与？
• AI应用应该如何构建？

Dify提供了低门槛的完整链路：模型接入、知识库、Workflow编排、应用管理、API调用——让技术团队可以快速完成从0到1的验证。

具体来说：

我们花了两周时间，用Dify搭建了第一个内部知识库问答应用，把公司的培训资料接入，验证了RAG能否回答员工问题。这次快速验证很关键——它让我们从"AI听起来不错"跳到"AI能力确实可以自建"。这个小胜利给了整个项目继续投入的信心。

为什么没有直接用 Agent 开发框架？

探索过程中我也关注过 Eino / LangChain / LangGraph 这类 Agent 开发框架。从技术角度看，框架提供更强的灵活性和控制力。

但企业AI落地早期，不可控因素太多。直接基于框架建设，意味着要同时承担：

• 较高的时间成本
• 较高的学习成本
• 较高的维护成本

而现实是，团队没有这么多资源可以投入。在验证阶段，最关键的是快速验证业务价值，所以选择平台化工具，是更现实的工程路径。

从 AI 应用，到平台能力沉淀

第一个工作流在Dify上调试成功后，我们很快面临下一个问题：如何让各个业务线接入AI。

API显然是最简单的方式——定义好输入参数，就能按照预编排的流程串联出处理逻辑。但更现实的问题随之而来：不同的接入方、不同的业务方，要怎么做隔离、应用隔离、权限控制？

我们当时的方案大致是这样：

• 测试环境：所有人可以在同一个平台里验证业务实现和自动化逻辑，全员开放。
• 低代码界面：让所有人能以可视化的方式理解AI应用——怎么组装节点、插件、接口，串联出某个场景的能力。
• 生产环境：仅少数人可以操作，保证能力的稳定性，对外只以接口形式交付。
• 通用能力封装：工作流、知识库检索、LLM接口统一封装，保证对外接口的稳定性。
• 权限路由：内部维护Dify的API接入权限校验，业务方只需在Header中传递应用名，即可路由到对应的工作流。

做到这一步，我们越来越感觉到，这套自己封装、提升易用性的平台，其实带着一些"中台"的影子——但又不完全是传统意义上的中台。

这也推动我重新思考AI应用与 Platform Engineering之间的关系。

软件工程的演进规律

过去几年，软件工程一直在解决一个问题：如何把复杂的系统变得更容易构建、更容易运行。

工程体系不断把复杂度沉淀到平台层：

单体应用
  ↓
微服务
  ↓
云原生
  ↓
Platform Engineering

走到这一步，我逐渐意识到：AI Agent平台的建设，本质上仍然延续着现代软件工程体系的核心架构—— Infra / Platform / Governance / Observability / Gateway。变化的是，这套架构正在针对Agent这一新范式的特定需求、新问题和更高目标，进行一次深度的重构、增强和特化。

Agent 进入工程化阶段

Agent不是2025年才出现的概念，早期已有探索——如何让大模型不仅生成内容，还能完成任务。真正的变化是：Agent正从实验形态走向工程化应用。

一个简单AI应用是：

用户 → 模型 → 回答

而真实的Agent系统，是多轮决策和执行的循环：

用户目标 → 任务理解 → 规划 → 工具调用 → 执行 → 反馈 → 调整

Agent的本质变化在于：它不再只是一次请求-响应，而是成为软件系统中的一种新的执行单元。

真正的工程，就像数据库或Kubernetes一样，是把复杂性隐藏起来：

• 应用开发者不需要关心如何扩展Agent（平台处理）
• 不需要关心如何监控和告警（平台处理）
• 不需要关心如何滚动更新（平台处理）

开发者只需要专注：我的Agent逻辑是什么，它需要什么工具。

Agent Platform

这是为什么我认为，企业AI平台会逐渐向Agent Platform演进。

从企业落地Dify开始，其实就已经预示着这条平台化的路径。我们最早解决的是如何让企业使用AI能力，而接下来要逐步解决的是：角色权限控制、租户隔离、工作负载的快速扩缩容、故障隔离，以及如何让大量智能体可靠、持续地运行。

它需要关注：

• Agent Runtime
• Workflow Orchestration
• Context Management
• Tool Management
• Observability
• Evaluation
• Governance

工程问题，才是真问题

回顾这段过程，Agent Platform Engineering并不是突然出现的方向，而是软件工程在AI时代的自然演进。过去，平台帮助开发者更高效地构建和运行软件；未来，平台需要帮助团队构建、运行和治理大量AI Agent。

回头看开篇那句话——程序员在AI时代的出路，或许就在这里：过去大家担心的是被AI替代，但当企业真的要把AI用起来时，会发现这中间有太多工程问题需要人来解决。