什么是 Agent-Native 基础设施？AI 开发者指南

Agent-native 基础设施让 AI agent 通过结构化接口发现、配置、检查和操作后端资源。Agent 可以在明确限制内独立完成配置，策略、账单和高影响操作的审批权仍由人掌握。

只有 API 并不足以让基础设施成为 agent-native。接口还需要机器可读的能力说明、范围受限的身份、可预测的错误、安全重试机制，以及供用户认领项目或审批操作的流程。

什么样的基础设施才算 agent-native？

Agent 可以发现可用操作

接口会告诉调用方有哪些操作、每个参数的含义，以及结果包含什么。这些说明可以放在 OpenAPI 文档、MCP 服务器、CLI 帮助或其他结构化契约中。具体格式并不关键，关键是 agent 无需将整个文档网站载入上下文，就能选择正确操作。

身份和权限属于调用方

每个 agent 或 agent 会话都应获得范围受限的身份。后端据此判断调用方能否读取或创建资源、产生费用或删除数据。共享管理员密钥会破坏这道边界，也难以追溯操作来源。OWASP 关于过度代理权的指南建议将工具功能、权限和自主程度限制在最低必要范围。AI agent 安全设计也讨论了同一问题：身份、权限和审计记录必须一致说明是谁执行了操作。

写入可以安全重试

Agent 会在超时、运行中断或工具结果不完整后重试。因此，写入操作需要幂等键或其他服务端去重机制。Stripe 的幂等契约是一个具体例子：服务端保存某个键的首次结果，在匹配的重试中再次返回。Agent-native 后端也需要这种特性，避免重复创建数据库、扣款或发送消息。

高影响操作始终受到限制

配置一次性开发数据库和删除生产环境中的存储卷，不应使用相同的审批规则。Agent-native 系统直接开放低风险路径，并在执行破坏性、付费或权限范围异常广泛的操作前暂停，等待策略检查或人工审批。生产环境 agent 检查清单将这项区别落实为具体控制措施。

Agent-native 基础设施与可通过 API 访问的基础设施

这是一项运维层面的区别。即使传统 API 被封装为 MCP 服务器，如果仍暴露权限过大的凭据、含糊的工具说明或非幂等写入，agent 使用起来依然困难。

为什么这种接口现在很重要

Vercel 在 2026 年 4 月报告称，由 coding agent 发起的部署在六个月内增长了 1,000%，占其平台每周部署量的 30% 以上。其中 75% 来自 Claude Code，6% 来自 Lovable 和 v0，1.5% 来自 Cursor。Vercel 还发现，agent 部署的项目调用 AI 推理提供商的可能性高出 20 倍。这些是 Vercel 平台的测量数据，并非整个市场的估算，但足以说明大型部署平台上的接口正在变化。

控制台默认用户可以理解含糊的失败提示、打开另一个标签页、复制密钥，再重试。Agent 则需要把这些状态表达成数据：缺少什么权限、重试是否安全、发生了哪些变化，以及哪项操作需要审批。

一个具体的配置流程

Cohesivity 的配置流程展示了这种模式。npx @cohesivity/init 创建项目上下文并写入 .cohesivity 文件。agent 随后可以通过同一项目请求资源，无需为每家提供商分别进入注册流程。项目可在 72 小时内认领，让 agent 有时间完成构建，同时由人保留最终所有权。

配置数据库、身份验证、存储和托管指南展示了请求和最终项目结构。这只是 agent-native 基础设施的一种实现，并不要求所有平台都捆绑相同服务。

如何评估 agent-native 平台

用一个真实任务检查完整流程：

1. agent 能否在没有纯文字配置说明的情况下发现操作？
2. 操作是否声明输入、输出、限制和稳定的失败原因？
3. 凭据是否只允许访问 agent 所需的项目和操作？
4. agent 能否重试写入而不重复产生影响？
5. 破坏性操作或付费操作是否会在执行前停止？
6. 人能否识别、认领、撤销并审计 agent 创建的内容？

未通过前两项检查的平台很难供 agent 使用；未通过其余检查的平台可能容易调用，却无法安全地无人值守运行。

测试一条配置路径

在一次性项目中运行配置，创建第一个资源后中断，再次发送相同请求。检查第二次运行是否顺利恢复、两次尝试是否共用一条操作记录，以及最终资源能否追溯到发起操作的 agent。

如果重试创建了第二份资源，也算有收获：你在测试中发现了缺陷，而不是凌晨 2:47 才在生产环境中遇到它。使用以下命令开始测试：

npx @cohesivity/init