AI 代理在开发者平台中的 3 种角色——以及每种角色需要什么

The New Stack 在 2026 年 8 月 29 日发表了一篇来自某平台团队（原文作者团队）的总结：在和数百个客户聊过之后，他们发现 AI 代理在开发者平台里扮演着三种截然不同的角色——代理作为平台的用户、代理作为业务流程中的一环、代理作为可供给的资源。这篇文章的价值在于它把「代理怎么用平台」这个模糊的问题拆成了三个清晰的模式，并且指出每种模式对平台能力的要求完全不同：有的需要 MCP 优先的上下文层，有的需要带代理身份的业务编排引擎，有的需要一条自助服务的黄金路径。搞混了角色，平台就会在错误的地方投入。

1. 角色一：代理是平台的用户

在这种角色里，代理基本上就是平台的一个用户：它把平台当作完成任务的一部分——读取上下文、执行动作。文章说，很多公司一开始都说「把 AI 代理当员工对待」，在开发平台里，这意味着代理只是又一个消耗平台的工程资源。典型场景：工程师让 Claude Code 给支付服务加一个端点。写任何代码之前，代理先从平台拉取服务负责人、依赖和它必须遵守的标准，然后通过自助服务动作拉起一个预览环境，跑测试。这个角色要求平台提供：API 和 MCP 优先的接口、代理可读取的受治理上下文层、一组可调用的自助服务动作。

// Role 1: the agent is a USER of the platform. Before
// writing code it pulls service ownership, dependencies,
// and standards from the platform -- via MCP, not scraping.
// From The New Stack: engineer asks Claude Code to add an
// endpoint to the payments service; the agent reads the
// service catalog, then spins up a preview environment.
{
  "tools": [
    {
      "name": "get_service_context",
      "description": "Return ownership, dependencies, and standards for a service. Server-verified.",
      "input": { "service": "string" },
      "output": {
        "owner": "team",
        "dependencies": ["string"],
        "standards": ["string"],
        "state": "current | deprecated | archived"
      }
    },
    {
      "name": "provision_preview_env",
      "description": "Create an isolated preview environment from a branch.",
      "input": { "branch": "string", "service": "string" },
      "output": { "url": "string", "expires_at": "date" }
    }
  ]
}
// "If you get the context wrong, there's a good chance an
// agent will get overconfident and do the wrong thing."

2. 角色二：代理在工作流里

第二种角色里，代理不再是「被请求」的，而是被事件触发的：它运行在平台内部，坐在编排引擎里，和确定性的步骤并排工作，成为完整业务流程的一部分。文章给的例子：每晚扫描 40 个服务，标记有漏洞的依赖。平台从注册表里拉出修复代理，对每个服务运行一次，于是每个负责团队早上醒来时，面前已经躺着一个待审查的 PR。这个角色要求平台具备：运行代理的编排层、能拉出正确代理的注册表、每个代理独立的身份（动作记录在代理名下，而不是借用的真人凭证）、以及在风险较高时的「人在回路」步骤。

// Role 2: the agent runs INSIDE a workflow, triggered by
// an event, next to deterministic steps. The platform
// pulls the right agent from a registry and runs it per
// unit of work -- e.g. a nightly vulnerable-dependency
// scan across 40 services, one remediation agent run per
// service, so each owning team wakes to an open PR.
const WORKFLOWS = {
  "nightly-dependency-remediation": {
    trigger: { type: "cron", schedule: "0 2 * * *" },
    steps: [
      { type: "scan", tool: "dependency-scan", scope: "all-services" },
      { type: "agent", agent: "remediation-agent", per: "service" },
      { type: "human", gate: "risk == high", approver: "service-owner" },
      { type: "pr", create: true, assign: "owner" },
    ],
  },
};
// The agent sits in the orchestration engine next to the
// deterministic steps -- it is part of a business process,
// not a chat.

3. 角色三：代理是可供给的资源

第三种角色里，代理和任何其他资源一样——LLM、MCP 服务器、技能，都是资源。平台负责供给、治理、回收，就像对待服务、数据库或环境一样。例子：工程师需要一个「值班分诊代理」。他选模型、选工具、选运行环境——通过表单或描述需求——平台把一切供给好，就像一台自动售货机，只不过吐出来的是一个治理良好的代理。文章强调，这就变成了黄金路径问题：默认情况下，能让团队以正确方式拿到资源的路径。代理生命周期也需要黄金路径：申请 → 供给并注册 → 发布给下一个团队。

// Role 3: the agent is a RESOURCE, provisioned like a
// database or an environment. The engineer picks the
// model, tools, and environment; the platform provisions,
// governs, and registers it. "A bit like a vending
// machine, with the addition of a well-governed agent."
async function provisionAgent(request) {
  const spec = {
    model: request.model || defaultModel(request.useCase),
    tools: filterToolsByPolicy(request.tools),
    environment: request.env || "sandbox",
    identity: await createAgentIdentity(request.owner), // per-agent, not borrowed human creds
    quota: { monthlyTokens: request.budget || 1_000_000 },
  };
  await registerAgent(spec);   // agent registry
  await grantPermissions(spec.identity, request.scopes);
  return spec;
}
// The golden path: request it, get it provisioned and
// registered, publish it for the next team.

4. 每种角色对平台的硬性要求

把三种角色并排看，要求差异非常清晰。角色一要求「上下文正确」：代理要基于服务目录推理，拿到负责人、依赖、标准和当前状态——「如果你把上下文搞错了，代理很可能过度自信然后做错事」。角色二要求「身份与审批」：每个代理有独立身份，高风险动作必须有人审批。角色三要求「黄金路径」：自助供给、治理、注册、发布。文章还透露了一个数据点：代理和技能注册表被 47% 的受访组织（2026 年初之前）明确要求——这是客户问得最多的能力。

5. 代码实战：MCP 上下文、事件工作流、供给

本文的五个代码块分别对应这些要求：代码块一用 MCP 工具定义演示角色一——get_service_context 返回服务负责人/依赖/标准，provision_preview_env 拉起预览环境；代码块二演示角色二——把「夜间依赖修复」工作流声明成事件驱动的步骤数组，代理作为其中一步按服务粒度运行，高风险时插入人工门禁；代码块三演示角色三——provisionAgent() 按规格供给代理：选模型、过滤工具、创建独立身份、注册、授权；代码块四是被治理的上下文层：每个代理按策略读取、每次读取都留审计日志；代码块五是代理与技能注册表的结构。

// The governed context layer (Role 1 requirement): one
// place agents read from, instead of local context wired
// to each agent in fragile ways. None of them governed.
class GovernedContext {
  async read(agentId, resource) {
    const policy = await this.policyFor(agentId, resource);
    if (!policy.allowed) {
      audit.deny(agentId, resource);
      throw { code: "FORBIDDEN", hint: "no access to " + resource };
    }
    const data = await this.source.read(resource);
    audit.read(agentId, resource, data.version);
    return data;
  }
}
// Same information, connected to agents the governed way:
// one context layer, policy per agent, every read logged.

6. 怎么选：你的平台现在是哪种角色

大多数平台不是「选一个角色」，而是会按顺序演进：先让代理当用户（角色一），因为它最容易起步——加几个 MCP 工具、一个上下文层就行；然后把它编进业务流程（角色二），让它从「被调用」变成「被触发」；最后让代理成为可供给的资源（角色三），把供给路径产品化。文章结尾的提醒很关键：很多团队「一个代理一个代理地提供本地上下文」来解决角色一的问题，结果同样的信息以脆弱的方式连到各个代理上，而且没有一个是被治理的。正确的做法是那 47% 的客户在要求的：一个注册表，一条黄金路径，所有代理都受治理。

// Agent and skill registry: requested by 47% of the
// organizations the platform team spoke with through
// early 2026. Publish once, reuse across teams.
{
  "registry": {
    "agents": [
      {
        "id": "oncall-triage",
        "version": "2.3.1",
        "owner": "platform",
        "model": "claude-sonnet-5",
        "skills": ["incident-triage", "runbook-lookup"],
        "approved": true
      }
    ],
    "skills": [
      { "id": "incident-triage", "version": "1.0.0", "owner": "sre" }
    ]
  }
}
// "That makes it a golden path problem. A golden path is
// the route that, by default, gets a team a resource the
// right way." -- The New Stack