核心摘要：过去二十年，我们在谈论 UX（用户体验）和 DX（开发者体验）。但在 Agentic AI（代理型 AI）爆发的今天，企业迎来了一批海量的“新员工”——AI 智能体。如果你的企业系统没有为它们提供良好的 AX（代理体验，Agent Experience），你收获的将不是生产力飞跃，而是系统崩溃、失控的 API 调用账单，以及一种全新维度的“影子 IT”。
作为企业的技术掌舵人（CIO/CDO），你可能刚刚费尽心思为员工部署了各种 AI Agent（AI智能体，以下统称 AI代理），期待它们能自动编写代码、分析数据、执行业务审批。
但现实往往是一盆冷水：这些 Agent 经常“碰壁”，要么找不到正确的系统接口，要么读不懂内部的文档，甚至因为一个报错就陷入死循环，疯狂向你的服务器发送请求。
为什么会这样？因为你现有的 IT 基础设施，是为“人类（需要图形界面）”和“传统软件（需要硬编码）”设计的，唯独没有为“具有自主推理能力的 AI”进行过设计。
Netlify 的 CEO Mathias Biilmann 提出了一个极具启发性的概念：AX（代理体验，Agent Experience）。就像 UX 决定了用户是否喜欢用你的产品一样，AX 决定了 AI Agent 能否在你的企业系统中顺畅、安全、高效地执行任务。
在数据与 AI 的转型中，CIO 们必须用批判性的眼光重新审视现有的技术栈，并在以下四个维度迅速采取行动：
当员工发现公司内部的 CMS（内容管理系统）或 CRM 系统的“代理体验（AX）”极差，导致他们的 AI 助手无法接入时，他们会怎么做？ 他们会抛弃内部系统。原文提到了一个真实的案例：一个营销团队直接弃用了刚花大价钱买的传统 CMS，转而让聊天机器人用简单的 Markdown 格式直接把内容更新到网站上。
CIO的批判性思考：如果你不主动改造内部系统的接口让 Agent 容易接入，业务人员就会绕过 IT 部门，去寻找对 Agent 友好的第三方外部工具。这不仅会让内部投资打水漂，还会引发灾难级的数据资产流失。
很多技术团队以为，只要给现有的 API 糊上一层 MCP（模型上下文协议），Agent 就能看懂了。这大错特错。 AI 基础设施公司 Jentic 的 CEO 犀利地指出：“AI 需要的是上下文，而不是更多的集成胶水。”
CIO的批判性思考：一个只会生搬硬套 API 接口的 Agent 是愚蠢的。你需要的是“上下文工程（Context Engineering）”。给 Agent 提供的不仅仅是 API 说明书，更是你们企业的业务逻辑、数据结构、甚至是过去发生过的错误排查日志。高质量的 API 治理、清晰的 OpenAPI 规范，才是企业 AI 能力真正的护城河。
人类遇到报错会停下来思考，但 AI Agent 不会。 “它们会不断尝试，无所不用其极……它们不会停下来，甚至能让你的服务不堪重负。”
CIO的批判性思考：代理型 AI 极度缺乏自我监管能力。它们的设计初衷是“达成目标”，而不是“优雅地失败”。因此，IT 基础架构部门必须在网关层建立强硬的护栏：强制执行幂等性、重试限制、Token 消耗配额以及熔断机制。如果不重视这一点，你月底收到的云服务和 API 调用账单将是个天文数字。
微软 CVP Amanda Silver 提出了一个极其精彩的理念：你需要一套“代理宪法”。 不要把商业规则隐藏在只有人类才懂的口头默契或晦涩的旧代码中。你需要用自然语言将企业的安全底线、审批规则、数据主权要求提取出来，变成 Agent 每次执行任务前都必须阅读的“元提示（Meta prompt）”。
“AI 代理只是一种恰好集成了大模型，并带有思维链的服务……剥去外衣，它仍然只是软件。”
面对这场轰轰烈烈的 AI 革命，CIO 和 CDO 最该做的，不是去盲目追逐最炫酷的智能体，而是静下心来，像过去二十年做数据治理和企业架构那样，把系统的 API文档写清楚、把数据的权限理干净、把业务逻辑变成机器可读的契约。
只有当你的企业系统具备了顶级的 AX（代理体验）时，那些聪明的 AI 代理，才能真正成为你麾下不知疲倦的超级员工。
摘要：UX（用户体验）和 DX（开发者体验）的宗旨是构建符合用户工作方式的系统和界面，从而提升用户和开发者的效率。AX（代理体验）则是针对 AI 代理的同等概念。
代理型人工智能（Agentic AI-或称：AI自主智能体）的核心意义在于它能通过编写代码、运行脚本、执行命令或调用 API来采取实际行动。如果这些操作从一开始就被设计得易于发现、文档齐全、保持一致，并且方便代理使用，那么代理的效率将大幅提升。
AI 代理所需的信息与人类略有不同。虽然两者都能从完整、准确、最新的文档或包含正确命令的错误信息中获益，但需求侧重点不同。例如，DevOps 代理需要了解整个 CI/CD 流水线的完整上下文，而人类开发者通常不需要。
不过，从总体上看，更好地管理业务逻辑、代码、数据、文档、API设计、策略和最佳实践，同样也会造福你的人类用户。如果你忽视了这些基础工作，你将面临一种全新层面的“影子 IT”风险——你的员工会转而去使用那些他们的 AI 代理能够顺畅配合的第三方服务。
“人们正开始相信并接受代理型 AI，但要真正实现它，还有大量的工作要做，”Forrester 副总裁兼企业架构首席分析师 Charles Betz 说道。AI 代理需要极其精确、结构化且易于访问的信息，而 AI 自身会放大系统的优点和缺陷。“如果你的系统难以被理解，你最终会得到一群晕头转向的 AI 代理，”他补充道。
让你的现有企业系统为迎接 AI 代理做好准备，这正是 Netlify 首席执行官 Mathias Biilmann 所称的 “代理体验 (Agent Experience, AX)”的一部分。AX 指的是 AI 代理作为平台或产品的“用户”时所遭遇的体验。
事实上，每一个产品和工具都已经拥有了某种形式的“代理体验”，因为 AI 代理已经在尝试使用它们。“现在的问题仅仅是：这种代理体验是好还是坏？”Biilmann 说。
如果你希望 AI 代理能够顺畅地使用你所依赖的产品或服务，了解该产品是否具备代理所需的基础设施至关重要。这包括：结构化且可预测的接口、全面的错误处理机制、用于多步骤工作流的会话持久性，以及实时反馈能力。
“代理是如何发现你的产品的？”Biilmann 问道。“是用户告诉它的，还是它自己推断出这可能是一个好方案？你该如何帮助代理理解它能用你的产品做什么？理想情况下，你该如何让代理轻松访问产品，同时尽量减少对用户权限的索取？然后，在整个代理的运行循环中，你该如何为它提供充足的上下文，以确保它能获得最佳的产品体验，并以最高效的方式为用户完成任务？”
“AX”这个术语已经在 AI 代码代理和开发者工具提供商之间流行起来，Biilmann 预计它将变得更加广泛适用。“随着从代码代理（尤其是 Claude Code）中获得的经验教训开始渗透到面向企业和消费者的代理中，”他说，“我们将看到下一层的工具和服务提供商意识到：如果我们不能与这些代理很好地配合，我们就会开始被边缘化或绕过。” Akamai 的最新研究表明，这种转变已经拉开帷幕。
在企业内部，提升 AX 意味着要打好基础，以便将代理型 AI 与现有系统有效整合。那么，你是把它们当回事后补救措施（比如像 RPA 那样从遗留应用程序中硬刮数据），还是确保你的工作流和工具从一开始就为 MCP(模型上下文协议)设定好了接口，从而让代理能够更高效地工作？
投资者们甚至已经开始谈论这些原则，将其作为对企业进行估值和预测代理主导型增长的依据。Anthropic 发布了关于如何编写能与代理良好协作的工具的指南；微软正在 Windows 中为代理构建具有访问限制的新账户，以确保它们安全运行。甚至有一家 AI 代码工具提供商直接弃用了他们刚花钱搭建好的 CMS（内容管理系统），仅仅是因为他们的 Cursor 代码代理无法轻松访问它。该公司的营销团队发现，让聊天机器人以 Markdown 格式将内容添加到网站上，比使用传统的 CMS 界面还要容易得多。
当然，作为一家构建 AI 代码工具的公司，即使是 Cursor 的非技术员工也具备相当的技术背景。在该提供商放弃 CMS 后不久，CMS 供应商就发布了一个 MCP 服务器，旨在让代理能够轻松创建、更新和管理网站，而无需进行如此极端的系统替换。但这生动地展示了 AI 代理对传统软件使用方式可能产生的巨大冲击。
Biilmann 提出了打造良好 AX（代理体验）的四个核心原则。这些原则基于：
代理是否能以正确的权限访问系统；
大语言模型（LLM）是否能获取正确的上下文以有效利用系统；
API、SDK 或命令行界面等工具的设计，是否允许代理将其作为接口来操作；
系统是否能够轻松触发和协调用户偏好的代理。
“现在出现了一个名为‘上下文工程 (Context Engineering)’的全新领域，它涉及 MCP、技能 (skills)、上下文文件，以及对工具响应的微调，旨在确保代理在使用你的产品时拥有最准确的上下文，”他说。他举例道，仅仅在 Netlify CLI 命令的错误信息中增加了一行输出，就从根本上改变了 AX——让代理从“无法使用该工具”变成了“能够一次性成功部署”。
但仅仅做一个封装了 API 的 MCP 是不够的。“你应该把 MCP 看作是代理的 UI（用户界面），它不仅能进行 API 调用，还能提供正确的上下文，让代理利用你的 API 高效完成任务，”他说。“给它提供上下文、数据结构，以及 API 端点通常是如何组合使用的说明。”
AI 基础设施公司 Jentic 的首席执行官 Sean Blanchfield 也认同这一点，他表示 AI 需要的是上下文，而不是更多的“集成胶水”。“如果你给 LLM 提供一份设计良好、文档清晰的 API 说明，它就已经可以直接与之交互了，”他说。“这使得高质量的 API 管理成为企业 AI 能力的真正基石。现有在 OpenAPI、API 网关、身份验证和治理方面的投资，将带来丰厚的 AI 红利。”
AI 代理还需要符合其规范的 API，而目前许多 API 都不符合要求。Jentic 提供的免费工具“AI 准备度记分卡 (AI Readiness Scorecard)”就是检查这一点的有效方法。
最常见的错误包括：引用的链接失效、OpenAPI 规范中的 Schema 格式错误、API 没有指明托管服务器，或者仅仅为人类开发者编写了身份验证信息（但这些信息无法通过 API 直接获取）。人类开发者也许能通过费力的手动操作绕过这些问题，但 AI 代理会因此陷入困境。
SaaS 平台 APIContext 的首席运营官 David O’Neill 指出，单纯的 API 规范并没有“操作顺序”的概念。因此，你需要使用 OpenAPI 的 Arazzo 工作流标准来对其进行编码。“突然之间，OpenAPI 规范和 Arazzo 工作流变得至关重要，因为 MCP 和代理系统正是通过这些来验证某个操作是否可行的，”他说。
Forrester 的 Betz 将这类工作称为 “生成式引擎优化 (Generative Engine Optimization)”，旨在帮助代理获取有关服务的详细信息。
“为 API 编写文档、对数据和信息进行稳健的业务定义、明确无误地了解这些数据的存储位置以及哪个系统是权威的数据源，这些都绝对是至关重要的，”他补充道。“你们的数据架构师和企业架构师在过去 20 年里一直试图建立的所有东西，现在正是 AI 完成其工作所急需的素材。”
博通（Broadcom）的资深技术专家 Michael Coté 表示，大多数组织都会使用一些老旧的代码和架构——他们既没有准备好将其淘汰，也不想再复制它们。“你必须仔细梳理，并标记出哪些是你认为‘表现良好’的数据库和数据架构，哪些是虽然能运行但你不喜欢的架构，”他说。
数据分析平台 KNIME 的 IT 总监 Martin Heyder 补充道，这其中有些属于基础的“IT 卫生”范畴，但依然至关重要。尤其是当你要自动化那些以前依赖员工手动从多个来源汇总数据的跨系统工作流时（这些数据以前甚至不需要保持实时更新或高可用性）。“如果系统的清单、日志或文档本身就不可靠，任何 AI 系统都会毫不留情地将这些错误信息自动化，”他说。
此外，AI 代理在初期往往会暴露出组织中依赖“隐性知识”运作的盲区。因此，跨代码库建立标准、强制执行代码审查，并为系统定义和文档保留单一的参考源，能为 AI 代理提供一个极其友好的操作框架。
微软负责应用和代理的 CVP（企业副总裁）Amanda Silver 将其称为 “代理宪法 (Agentic Constitution)”。这是一种使用自然语言来规定组织或代码库中常见需求或期望的方法。“你必须确保 AI 代理始终将这些规则置于其上下文之中，”她说。
这一概念可以应用得更加广泛，甚至作为一种“元提示 (Meta prompt)”。它可以在代理需要管理身份权限、创建“人机协同 (Human-in-the-loop)”界面，或者构建允许你观察代理操作日志的系统时，为其规定具体的行为方式。
针对现有基础设施的身份认证、访问管理和权限控制是重中之重。大多数组织可能需要从盘点资产开始，确保他们清楚了解所有希望 AI 代理与之交互的系统，并在必要时能够对其进行更新。
这可能意味着企业需要添加新的 API，甚至替换掉那些核心逻辑和用户界面严重耦合的遗留应用程序。因为对于 AI 代理来说，使用内置了 API 或采用了可组合无头架构（Headless architectures）的 SaaS 应用要容易得多。例如，IDC 接触的组织中，有近 30% 正在研究如何实现其整个软件组合的现代化，以便更好地利用 AI 和代理。
“AI 代理能够实现最高投资回报率 (ROI) 的任务是后端工作流的处理，”Silver 说。“你可能会使用像 MCP 这样的协议向代理暴露数据，但这并不意味着它们就能采取行动。你需要思考：你想要自动化哪些动作？你可以将哪些动作作为工具暴露给代理？它们能调用哪些接口，从而实现从意图、到计划、再到实际执行和行动的完整闭环？”
如果你希望 AI 代理在解决系统故障时发挥作用，它们就需要访问 API，以便将信息添加到你们汇总事件详情的仪表板中。工作流也需要将代理纳入其中，以便它们能够订阅关键事件（比如订单是否已发货、发票是否存在争议），并能够触发正确的后续操作。
此外，现有的业务政策可能被硬编码在系统里，而不是以书面形式记录。现在需要将它们提取为代理可以访问的自然语言政策文档。随着组织开始使用更多的代理，Silver 认为他们不仅需要覆盖整个工作流的顺序编排（Sequential orchestration），还需要进行“对抗性评估 (Adversarial evaluation)”。因为复杂的工作流可能需要遵循多个相互制约的政策，它们都在试图实现特定的结果。“为了解决这个问题，你可能会实施带有政策约束的多代理编排。你可以向多个‘专家代理’进行咨询，然后让这些专家代理回来做出最终的判断，从而满足用自然语言编码的多种政策要求。”
早期的采用者已经发现，AI 代理可能是“无情”的，并且极易发出海量的并发查询。“它们会不断尝试，无所不用其极，”Biilmann 说。“它们不知道停下来，甚至可能会让你的服务不堪重负而崩溃。”如果你无法重新设计 API 让其返回操作提示（比如因为该 API 是第三方的），你就必须在自己这端实施配额限制或对查询进行优先级排序。
“我认为未来将会出现大量人工创建的‘场景护栏’，因为代理型 AI 在自我约束方面表现得非常糟糕，”O’Neil 说。“它的设计初衷是不达目的誓不罢休，而不是在遇到挫折时自动关闭。”
Betz 补充道，为了防止 API 被失控或重复消耗，必须强制执行幂等性（Idempotence）、重试机制、配额和访问限制。“AI 代理并不是无限的资源，如果它们无法获得正确的答案，它们必须知道什么时候该放弃尝试，”他说。
注：幂等性（Idempotence）
定义：同一操作执行 1次或N次，对系统状态的影响完全相同（数学表达：f(f(x)) = f(x)）。
为什么重要：分布式系统中网络抖动、超时易导致重复请求。若操作非幂等，将引发数据错乱（如重复扣款、重复创建订单）。
典型场景：
✅ 幂等：HTTP GET（查询）、PUT（用唯一ID更新）、DELETE（删除已存在资源）
❌ 非幂等：HTTP POST（每次创建新资源）、计数器+1
实现方案：
客户端生成唯一 Request-ID，服务端校验是否已处理
业务层加锁/状态机（如“订单状态=已支付”则跳过）
数据库唯一索引（防重复插入）
💡 示例：支付接口以“订单号+用户ID"为幂等键，重复请求直接返回原结果。
Silver 表示，AI 治理的一部分就是清楚地了解哪些 MCP 是向代理开放的。“你可以随时撤销它们对特定 MCP 的访问权限，管理其 Token（算力代币）的消耗，并强制执行对你和你的组织有意义的治理策略，”她说。
Biilmann 指出，AX（代理体验）和 UX（用户体验）是一门类似的学科，它同样是迭代的，核心都在于深刻理解用户（或代理）到底想要完成什么任务。“你必须组建一个专门的团队来进行研究，找出问题和机遇，”他说。这意味着你需要查看代理的会话回放、识别导致代理失败的行为，并构建更友好的响应和接口来帮助它们取得成功。
随着代理底层的 AI 模型不断进化，Netlify 发现他们不再需要像以前那样严重依赖添加上下文文件来引导代理访问最新的 API。但这只意味着问题变成了移动的靶子。“你必须面对一批全新的代理受众，不断地与它们磨合和迭代，”他说。
O’Neill 表示，那些已经在使用 MCP 的 APIContext 用户发现：事务的数量、涉及的 API，甚至代理使用的具体服务，都可能发生出乎意料的变化。“当 MCP 返回的服务发生了改变，代理就会尝试用另一种完全不同的方式去创建记录，而旧的路径就行不通了，”他说。“这不像传统的 API 网关，所有东西都是你事先定义好的。它更像是一个黑匣子，只是简单地甩给你一份可用的工具清单。”
一种新型的 MCP 服务器性能监控工具可以让你检查和设置警报，并基于性能阈值、规范要求、网络功能，甚至是为了满足数据主权的数据传输规则，来创建治理策略。AI 代理要求我们对 API 管理倾注前所未有的关注。“这将迫使人们极其认真地对待 API 治理，”O’Neill 补充道。
此外，Betz 建议，除了治理工具、监控和可观测性平台之外，还要依靠你的 API 网关。“说到底，AI 代理只是一种恰好集成了大语言模型（LLM），并带有一些思维链（Chain of Thought）、意图管理和目标导向行为的服务而已，”他说。“剥去外衣，它仍然只是软件。”
这意味着企业的日志记录基础设施将承受巨大的压力。“如果你全面拥抱代理型 AI，并试图追踪所有的代理活动，你会发现这些网络流量会以某种高度非确定性的方式在系统中疯狂跳跃，”他说。Silver 表示，归根结底，衡量 AI 代理是否成功，不仅关乎最终的产出结果，也关乎整个过程的可观测性（Observability）。“随着时间的推移，你需要评估代理是否真的按照你的意图执行了操作，同时更要确保它没有在执行过程中完全脱轨，”她说。
微软已经在其站点可靠性工程（SRE）中广泛使用了 AI 代理，以降低响应线上故障的成本并缩短修复时间。“为了做到这一点，你需要拥有贴好标签、带有时间戳、且完全可追溯的数据供你审查，”她补充道。“你还需要拥有丰富、结构化的信号，并且从结果导向的视角出发，极其清晰地界定什么是‘好’、什么是‘坏’。”
