我们是否缺少一个面向AI智能体的运维层？
摘要
本文探讨了AI智能体在生产环境中运维工具的缺失，重点关注错误处理、状态重放、安全性和审批流程等挑战。
在阅读了一系列关于Agent DevOps和小团队讨论后，我不断看到相同的模式。问题不再仅仅是“这个代理能否一次性完成任务”。当代理开始接触真实系统时，更困难的部分就开始了。如果它在执行中途卡住，你是应该重试、恢复、停止，还是交给人工处理？如果它已经调用了工具、修改了数据、发送了消息或部署了某些东西，你怎么知道哪些部分可以安全地重放？谁负责管理凭据和审批步骤？代理应该看到完整的策略规则，还是只收到简单的拒绝/原因回复？有用的运行历史应该显示什么——提示词、工具调用、状态、审批、外部副作用、回滚路径？感觉“agent runtime”和“agent operations”正在变成两个不同的问题。很好奇这里的人们是如何处理这个问题的。你们是在内部构建基础设施，拼接现有工具，还是暂时不让代理接触生产级操作？
相似文章
在AI代理投入生产之前，还缺少哪些基础设施？
关于运行AI代理所需基础设施缺失的讨论，包括监控、权限、恢复和审计追踪，质疑这是否会成为新的基础设施类别。
AI智能体在实际工作流中真正失败的地方（非演示环境）
讨论AI智能体在实际工作流中失败的地方，重点指出协调问题、混乱输入下的可靠性问题，以及在生产中减少人工干预的挑战。
我认为AI代理将需要一个操作层
作者认为，随着AI代理变得越来越自主，需要一个治理层来实现控制、可观测性和可审计性，并介绍了Bendex Arc作为解决方案，其组件包括Arc Gate、Arc Replay、Arc Approve和Arc Memory。
按治理层而非功能列表划分的AI智能体管理工具
分析指出，大多数企业AI智能体安全投资集中在模型层护栏和可观测性，在访问层和协议层留下了关键缺口。援引2026年报告，75%的企业AI智能体仍处于未保护状态，原因是这些层的覆盖面几乎为零。
AI智能体中最无聊的部分：没人构建，人人都需要
一位实践者回顾了在生产环境中部署AI智能体的经历，指出80%的工程精力花费在工作流、所有权和审批流程上，而非模型本身。他强调，共享上下文和路由这些“无聊层”对于产生实际影响至关重要。