Werner 用 Nitro 的“被动通信”设计做类比：虚拟机监控程序不能主动联系 Nitro 控制器，反之视为异常。这套原则延伸到了 Agent 的权限控制——用户必须先授权系统能做什么，一旦 Agent 自主发起未经许可的动作，即被拦截。Nitro 将虚拟化功能卸载到专用硬件（VPC / EBS 加速卡），释放 30% 的 CPU 资源，同时通过硬件级安全芯片和固件验证缩小攻击面。从 DynamoDB 到 Nitro，再到 Agent，Werner 的设计哲学一以贯之：系统不该假设组件永远可靠，要用硬件/代码级别的强制边界替代信任。

Werner 用 2004 年数据库故障引出 DynamoDB 的诞生。很多人不知道，Dynamo 的前身论文《Dynamo: Amazon's Highly Available Key-value Store》发表于 2007 年，核心创新是用一致性哈希、向量时钟和 Gossip 协议实现 AP（高可用 + 分区容忍），放弃强一致性。这个设计直接影响了后来的 Riak、Cassandra 等 NoSQL 系统。DynamoDB 则是在此基础上由 AWS 托管的全托管服务，支持键值和文档模型，做到个位数毫秒级延迟和 99.999% 可用性。当年那条“70% 的场景只需要键值访问”的发现，才是从关系型大锤转向专用工具的起点。

Werner 坚持开发者兜底，但法律界有不同分层。杭州互联网法院的全国首例 AI 幻觉案判决认定：通用对话 AI 的输出不能视为企业意思表示。但凤凰网法律专家指出，一旦 Agent 被嵌入客服、交易等业务流程，其输出很可能构成民法上的“意思表示”，企业须为此负责。新华网报道进一步提出“链式分层问责”：开发者对能力边界负责，部署者对规则设置负责，用户对使用后果负责。三种立场的分歧集中在“AI 输出是否算有效承诺”——企业部署 Agent 前，必须先想清楚自己站在哪个位置。

Werner 提出“验证债”：AI 生成代码的速度远超团队审查能力，未被验证的代码就像一笔新的技术债，但性质不同——它不欠架构清晰的账，欠的是“这个 AI 输出到底对不对”。界面偏几毫米和泄露客户数据的代码，风险天差地别。对企业来说，下一步的关键变量是：团队能否建立按风险分级的自动化验证流水线（如单元测试+合规扫描+生产影子测试），否则今天 AI 省下的时间，很快就会在排查和返工中加倍花掉。结论不是少用 AI，而是要在 AI 加速代码生产的同时，等比例投入代码验证能力。

Werner 反复强调“你构建它，你就对它负责”，但真正值得追问的是：当 Agent 的自主决策链变长、模型输出不确定时，开发者能否在工程上准确定义“边界”？业内已出现零信任权限模型和五层权限体系（数据 / 工具 / 动作 / 审批 / 审计），但核心麻烦在于：大模型的幻觉和涌现行为，使得“预期行为”本身就是一个模糊概念。与其问“AI 犯错谁来赔”，不如问“开发者到底要在哪里画下那条 Agent 不能越过的线，以及这条线能被代码执行多牢”。