文章揭示企业AI代理风险，强调部署前需明确能力边界。通过系统测试、模拟和共享理解，结合Microcks等工具，可实现安全高效的AI集成。
译自：Before you let AI agents loose, you’d better know what they’re capable of
作者：Charles Humble
对于企业而言，代理式AI系统可能使员工职责从执行转向判断、监督和战略。这创造了新的机遇，但也充满了风险：
- 失去人工监督和控制：代理式系统可以采取一系列自主行动，例如浏览网页、执行代码、调用API和管理文件，通常只有极少的人工检查点。这会产生复合风险：一个早期错误可能在任何人注意到之前就演变成重大损害。企业可能难以审计采取了哪些行动、何时以及为何采取，从而使问责和补救变得困难。
- 安全和提示注入漏洞：消耗外部数据（网页、电子邮件、文档）的代理容易受到提示注入攻击，即环境中恶意内容劫持代理行为。在企业环境中，一个受损代理如果能够访问内部系统、数据库或API，则可能在看似正常运行的同时，窃取敏感数据、提升权限或执行破坏性操作。
- 不可预测且难以撤销的行动：与仅生成文本的聊天机器人不同，代理式系统会采取真实世界的行动：发送电子邮件、修改记录、进行购买和部署代码。错误可能难以甚至无法撤销。广泛的工具访问、漫长的任务周期和模糊的指令相结合，会创造出代理以技术上正确但操作上灾难性的方式追求目标的场景。
此外，代理的使用可能导致对代理敏感决策判断的过度依赖、代理摄取机密上下文产生的数据隐私风险，以及代理调用外部服务时产生的第三方供应链风险。
“一个早期错误可能在任何人注意到之前就演变成重大损害。企业可能难以审计采取了哪些行动、何时以及为何采取。”
由于代理式AI是如此新颖，我们还没有可借鉴的模式或最佳实践。相反，作为IT专业人士，我们需要在我们中间找出风险缓解措施，并希望在过程中公开分享我们所学到的东西。开源API公司 Naftiko 的联合创始人兼首席社区官 (CCO) Kin Lane，从系统思维的角度看待代理式风险的缓解。他的主要论点是，测试和模拟是企业为代理式系统做好准备，并能充满信心和安全地应对的方式。
行为即规范
系统思维中最著名的启发法之一是由已故的Stafford Beer提出，他是一位英国理论家、顾问，也是曼彻斯特商学院的教授。他经常使用这句话：“一个系统的目的就是它所做的事情”——这意味着一个系统经常以与设计、操作和推广它的人的意图相悖的方式运行。“毕竟，”Beer观察到，“声称一个系统的目的是做它不断失败的事情是没有意义的。”
如果一个系统的目的确实是通过其行为而非其设计来揭示的，那么理解Donella Meadows所指的“和”——组件之间的关系——就需要能够可靠地可观测性系统。
“一个系统的目的就是它所做的事情。毕竟，声称一个系统的目的是做它不断失败的事情是没有意义的。”——Stafford Beer
可观测性工具，如Honeycomb，使用分布式追踪和高基数事件数据来提供对生产中系统行为的洞察，使工程师能够实时查询和探索遥测（跨度、追踪和结构化日志字段）的任意维度。但对于代理式系统，我们还需要在生产之前获得信心。
Lane认为这可以在测试套件中找到；他说，测试允许你主动塑造行为，进而塑造API的未来。
“人们倾向于将API测试视为确保它做它应该做的事情，”他告诉The New Stack。“但拥有强大的沙盒并使用契约测试与消费者建立强大的反馈循环相结合，可以让我们迭代未来。拥有良好测试实践的公司在发明和应对未来方面都做得更好。他们能够以生产者和消费者都认同的可靠、可重现的方式将事物变为现实。”
正是这种思维模式，他带入了为其客户定义业务能力的工作中——本质上是描述一个系统能为企业做什么（如“处理支付”或“管理库存”）的离散、可组合的单元。他构建沙盒和模拟，从而为他们的AI代理提供一个安全的“游乐场”。
为了使他的方法奏效，模拟需要准确地代表现实。“我应该能够将模拟的URL切换到生产环境，并可靠地获得具有相同结构的实时响应，”他说。“这相当于一个测试；我能否从合成模拟无缝过渡到生产环境？”
如果做得好，模拟和契约测试会相互强化。脆弱、不切实际的模拟表明契约测试很差或根本不存在，而不是模拟本身的失败。如果API生产者和消费者之间没有共享可见性，模拟和真实的API就会独立演进，这可能会破坏信任。当提供者发布正式规范和示例，并在他们自己的契约测试中使用它们时，每个人都会保持一致。
为了实现这一点，Lane偏爱开源工具，特别是Microcks和OpenAPI，并使用Bruno进行脚本编写。
共享模拟，共享现实
Microcks是一个用Java构建的开源API模拟和测试平台，已经运行了十年，并在三年多前捐赠给了云原生计算基金会（CNCF）。它专为企业规模设计，与语言无关，支持REST/OpenAPI、AsyncAPI、Kafka、MQTT、WebSockets、gRPC、GraphQL等。
这种广度是无价的，因为企业环境通常会分层使用多种API标准——我在本系列的前一篇文章中将其称为API沉积——而不是标准化为一种。如果没有像Microcks这样的工具，“你最终会为每种协议或规范配备一个专用工具，这简直是噩梦，”Microcks的联合创始人Yacine Kheddache告诉我。“出于模拟目的，开发人员会创建自己的虚拟模拟，这些模拟并不能代表真实的业务服务。”
该平台围绕契约优先的理念构建。导入主要工件（如OpenAPI规范）后，Microcks会利用它自动生成模拟端点，无需编写代码。为避免主规范因数百个示例而变得臃肿，Microcks支持次要工件，即来自Postman集合、HTTP存档记录、AI副驾驶或手动编写的YAML文件的额外示例集。将主要和次要工件捆绑在一起，可生成采用者描述为“沙盒即服务”的即时沙盒。
一个显著的特点是Microcks如何鼓励组织范围内的协作。“不仅仅是开发人员在维护用于单元测试的一次性本地模拟。团队构建共享的、版本化的示例数据集，API服务周围的全球每个人都可以贡献和重用。”
Kheddache说。这使得微服务团队能够并行开发：开发人员模拟其依赖项，独立工作，并在真实服务可用时简单地替换进去。
大型采用者，包括Amadeus，利用Microcks将模拟和契约测试方法“左移”，报告称开发速度显著提升。
Microcks 在 BNP Paribas
Kheddache所描述的协作、共享所有权模式并非理论。在BNP Paribas，法国零售银行部门的32个团队现在正在使用Microcks，有超过500名开发人员和测试人员活跃在该平台上，每周通过它处理超过250万次API调用。
BNP拥有一台庞大的传统大型机，位于核心银行操作的中心，每个团队在需要构建或测试时都必须直接与之交互。这既缓慢又昂贵，并给运行成本高昂的基础设施带来了不必要的压力。
通过在Microcks中模拟那些由大型机支持的API，BNP的团队可以并行开发和测试，而无需接触大型机，并且只在真正必要时才连接到真实服务。根据已发布的案例研究，结果是开发和测试周期缩短了三分之二。
还有一个意想不到的收获：大型机负载的显著降低直接转化为更低的能耗，这是对银行可持续发展目标的有意义的贡献，而这并不是你通常会与测试工具联系在一起的结果。“在任何地方部署随时可用的模拟沙盒的能力，”BNP团队指出，“是实现这种规模化运作的核心。”
这正是Kheddache在描述平台更广泛前景时所设想的结果。“当他们采用我们的方法时，所获得的成功令人难以置信，”他告诉我。“他们能够加快开发速度，模拟所有依赖项，并且每个人都可以并行工作。”
对于契约测试，Microcks可以充当API客户端，向真实端点发送请求并验证它在多个版本中仍然符合其契约。这对于捕获破坏性更改和验证向后兼容性非常有用。
Microcks也已转向支持个体开发人员，而不仅仅是集中式平台团队。一个轻量级的原生二进制文件（通过GraalVM编译）在200毫秒内启动，并且存在适用于Java、Node、Go和.NET的Testcontainers绑定（最后一个由AXA Insurance贡献）。开发人员现在可以在本地运行完整的集成测试，使用与中央环境相同的共享示例数据集，从而弥补了“在我的笔记本电脑上能运行”的差距。
现在，每个Microcks模拟端点还公开一个模型上下文协议（MCP）链接，使模拟API可作为工具供大型语言模型（LLM）和AI代理访问。第二个目前尚未命名的项目正在开发中：一个运行时代理，可将OpenAPI、GraphQL和gRPC规范转换为生产环境的MCP服务器，并带有秘密管理和自定义工具塑形功能，使API能够被语言模型更可靠地使用。
AI 分割反馈循环
通常，在测试和模拟的背景下，使用沙盒的利益相关者越多，你就越有可能实现全面而可靠的模拟。然而，将生成式AI加入其中，就像编程本身的行为一样，我们仍在努力理解健康的反馈循环是什么样子。“从历史上看，健康的反馈来自于所有利益相关者在同一个工作区、仓库或会议室的白板上。但AI进一步碎片化了这些，所以我必须重新思考，我还没有一个好的答案，”Lane说。
“内部和外部API的菜单就是你公司能做的事情。如果你没有在一个目录、沙盒或注册表中拥有它，以便你可以测试、试用和理解它，你的团队就不会知道你有什么能力。”——Kin Lane
像Microcks这样的工具使契约驱动的模拟变得容易，但协作和共享所有权才是使其发挥作用的关键。随着代理式系统获得更多的自主权，对系统能够做什么以及应该做什么的共享理解成为其他一切的基础。
