AI Agent在开发者平台中的三种角色

工程团队正在尽可能快地交付产品，将 Agentic AI 引入开发者平台，并探索如何使用 AI Agent 来最大化工程生产力。

但说到 Agentic 开发者平台中的 AI Agent，每个团队对这些 Agent 的角色理解都不尽相同。在与客户进行了数百次沟通后，我们总结出三种类型的角色。

角色 1：AI Agent 作为平台消费者

在这个角色中，Agent 本质上是平台的用户。它将平台作为任务的一部分来读取上下文并执行操作。Agent 最初出现时，许多公司表示他们将 AI Agent 当作员工对待，而在开发平台中，这意味着 Agent 成为另一个消费该平台的工程资源。

一个典型案例：工程师让 Claude Code 为 payments 服务添加一个端点。在编写任何代码之前，Agent 从平台获取服务负责人、依赖关系及其必须遵守的标准，然后通过自助服务操作启动一个预览环境并运行测试。

"许多公司表示他们将 AI Agent 当作员工对待，而在开发平台中，这意味着 Agent 成为另一个消费该平台的工程资源。"

要实现这一点，Agent 必须对系统的真实、当前信息进行推理，从服务目录开始，延伸到所有权、依赖关系、标准以及当前状态。如果上下文获取错误，Agent 很可能会过于自信而做出错误的操作。大多数团队通过为每个 Agent 提供本地上下文来单独解决这一问题。但随后相同的信息以脆弱的方式连接到各个 Agent，更不用说这些 Agent 都缺乏治理。相比之下，上下文湖为每个 Agent 提供单一且被治理的真实数据源，这是完全不同的解决方案。平台还必须以 Agent 的工作方式可达，这意味着要优先采用 API 和 MCP。

这对平台有什么要求？API 和 MCP 优先的接口、Agent 可以读取的治理上下文层，以及它可以调用的自助服务操作集。

角色 2：AI Agent 作为内部平台组件

能够注册 Agent 并在工作流中运行它们的平台，正在将 AI Agent 作为完整业务流程的一部分来使用。Agent 在平台内运行，由事件触发而非人员请求触发，并位于编排引擎中，与确定性步骤并列。

例如：运行一个夜间扫描，在 40 个服务中标记存在漏洞的依赖项。平台从注册表拉取修复 Agent，为每个服务运行一次，因此每个负责团队醒来时都会看到一个待审核的开放 PR。

这对平台有什么要求？用于运行 Agent 的编排层、从哪里拉取正确 Agent 的注册表、每个 Agent 的身份标识（以便操作被记录在 Agent 而非借用的用户凭证下），以及在风险显著之处设置人工审批步骤。

角色 3：AI 作为拥有自身生命周期的资源（即 AgenticOps）

在这个角色中，Agent 与其他资源无异，LLM、MCP 服务器及其附带的技能同样如此。平台负责配置它们、治理它们，然后交回它们，就像对待服务、数据库或环境一样。

举例来说，假设工程师需要一个值班分诊 Agent。他们通过表单或描述需求来选择模型、工具及其运行环境，平台配置好一切——有点像自动售货机，但额外提供了一个符合正确标准的、被良好治理的 Agent。

"这使其成为一个黄金路径问题。黄金路径是一条默认情况下能让团队以正确方式获得资源的路线。"

这使其成为一个黄金路径问题。黄金路径是一条默认情况下能让团队以正确方式获得资源的路线，Agent 生命周期也需要一条：请求它，获得配置和注册，然后发布给下一个团队。这也是客户向我们请求最多的东西，截至 2026 年初，接受调查的组织中有 47% 提出了 Agent 和技能注册表的需求。我之前在关于黄金路径的文章中更深入地探讨过这一点。

这对平台有什么要求？一条配置运行时的自助服务路径，颁发身份标识和范围凭证，接入已批准的上下文，并在出口处注册 Agent，同时还要有一条发布路径供下一个团队使用。

三种角色一览

角色	Agent 的角色定位	示例	对平台的要求
角色 1：AI Agent 作为平台消费者	平台的用户，作为任务的一部分读取上下文和执行操作	Claude Code 获取服务负责人、依赖关系和标准，然后启动预览环境并运行测试	治理上下文层（如上下文湖）以及 Agent 可调用的自助服务操作
角色 2：AI Agent 作为内部平台组件	工作流中的一个步骤，由事件触发而非人员请求	夜间扫描在 40 个服务中标记漏洞依赖，修复 Agent 为每个服务打开一个 PR	运行 Agent 的编排层、拉取正确 Agent 的注册表、每个 Agent 的身份标识，以及在存在真实风险时的人工介入
角色 3：AI 作为可复用构建块（AgenticOps）	平台配置、治理并交回的资源	工程师请求一个值班分诊 Agent，选择模型和工具，获得一个已注册的 Agent	配置运行时的自助服务路径、颁发身份标识和范围凭证、接入已批准的上下文，并在出口处注册 Agent

有时三种角色会相互连接

链接案例是一个有趣的场景。工程师通过角色 3 请求一个分诊 Agent；它作为创建工作流的一部分被添加到 Agent 注册表，一周后，事件工作流将其作为组件调用（角色 2）。当它运行时，它从同一个上下文湖中读取服务所有权和近期部署信息，这是角色 1。整个过程中它是同一个 Agent，它处于哪个角色取决于你何时观察它。

"它是同一个 Agent 贯穿始终，它处于哪个角色取决于你何时观察它。"

覆盖全部三种角色的平台是什么样的？

这就是我们为 Port 构建的东西。Agent 可以通过服务账户作为用户使用 Port，读取上下文湖并执行自助服务操作。Agent 在 Port 工作流内作为业务流程的一部分运行。AgenticOps 作为自助服务工作流运行，因此团队可以请求一个 Agent 并获得一个已注册的 Agent 回来。全部三种都建立在同一个目录、同一个上下文和同一条审计日志之上。

如果你想要完整的内容，可以阅读我们的 playbook：《从 Agentic 混沌到 AI-Native SDLC》。