思科DevNet平台工程团队Matt Shooshtari：判断AI智能体能否进生产，看凭证不看演示

任何厂商现在都能给你看一场令人印象深刻的智能体演示。但几乎没有人能在演示之后给你一张凭证。Shooshtari认为，信任恰恰来自这张凭证，而非演示本身。

他描述了一个具体场景：智能体在夜间向集群推送了一个变更，第二天有人问谁批准了这次部署。如果唯一的记录是模型自己写的操作摘要，诚实的回答只能是'靠记忆和善意'。演示展示的是智能体能做什么，不是它被允许做什么，也不是事后谁能知道发生了什么。

Shooshtari给出的四个评估问题是：它能碰什么，模型有没有投票权？关键操作由谁批准？事后能否向任何人证明发生了什么？凌晨三点的自主运行和下午两点的实时请求是否经过同一道门？

这四个问题背后是一个具体的架构原则：模型提议，策略引擎判断。在CadreAI中，语言模型永远不决定一个操作是否可以执行。每一次工具调用，哪怕只是读取一个文件，都先经过一个确定性策略引擎。引擎检查调用者的身份和角色，对重要操作还检查具体参数。模型可以提议任何它想做的事，但它不兼任裁判。当引擎说不行时，智能体如实报告拒绝，不会寻找绕过方式。

这里的机制要点是：你通过编辑策略来划定智能体的范围，没有任何提示词能说服模型跳过一条它从未被要求评估的规则。每个请求得到三种回答之一：直接拒绝、转交人工审批、或者因为是常规操作而放行。部署位于审批门之后——人在操作接触生产集群之前审查具体变更和试运行结果，部署之后智能体检查实际工作负载，而不是因为脚本返回零就假设一切正常。

审计日志是那张凭证。CadreAI把每个操作——无论允许还是拒绝——写入一条哈希链审计日志。每条记录与前一条的哈希绑定，事后修改任何一条都会断链。日志保存的是实际决策和实际参数，不是模型自己写的摘要。没有它，'谁批准了那次部署'的答案取决于记忆和信任；有了它，答案是任何人都可以核查的记录。

第四个问题——凌晨三点是否和下午两点一样——针对的是自主运行。CadreAI按自己的计划唤醒，每次唤醒经过与实时对话相同的门。没有因为没人看着就获得额外权限。

在角色设计上，这不是一个拥有全部访问权限的智能体。邮件和日历在一个专家智能体里，工单集成在另一个里。每个智能体证明自己的身份，在被授予角色之前不持有任何权限。Shooshtari用DevOps文化类比：拆掉团队之间的墙不意味着没人拥有任何东西，一个专家智能体的爆炸半径——它状态不好时能造成的损害——留在它的角色之内。

需要说明的是，这是CadreAI构建者对自己系统的描述。框架的逻辑——提议与判断分离、哈希链日志、一致的权限门——是可独立评估的设计原则，但CadreAI是否确实按所述方式运行，属于厂商自述，本文无法独立验证。

对正在评估智能体部署的团队来说，可操作的收获是：下次看完演示，不要问'它能做什么'，要问'它做了之后能向人证明什么'。如果答案只是模型自己的一段话，那和没有记录没有区别。