有界自主性：消费端的类型化动作契约在企业软件中阻止大语言模型错误
为什么重要
新 arXiv 论文提出了一种企业 AI 的架构解决方案：不是在模型端防止大语言模型 (LLM) 错误，而是在消费端定义类型化动作契约，以静态方式检测未授权操作、格式错误的请求和跨工作区执行。该方法将安全负担从概率性模型转移到确定性类型系统。
问题是什么？
在企业软件中——CRM、ERP、内部工具、客服平台——AI 智能体越来越多地执行有后果的操作：更新记录、发送邮件、触发工作流、访问不同客户的工作区。当大语言模型 (LLM) 以突破安全边界的方式出错时，问题就出现了：
- 未授权操作 — 智能体执行用户无权限的功能
- 格式错误的请求 — 工具调用结构违反预期格式，API 崩溃
- 跨工作区执行 — 在多租户环境中，智能体接触到其他客户的数据
- 未授权提权 — 智能体使用需要比用户授权更高特权级别的工具
经典解决方案是”更好地训练模型”或”在提示词中添加护栏”。两者都是概率性的——模型仍然可能出错，只是频率较低。在企业环境中，一个错误可能意味着 GDPR 违规或客户信任损失，这是不够的。
论文提出的解决方案
2026 年 4 月 17 日在 arXiv 上发表的论文提出了一个模型外的确定性层：
- 类型化动作契约明确定义智能体可以执行哪些操作、使用什么参数、在什么上下文中、以及在什么前提条件下
- 消费端执行意味着大语言模型 (LLM) 不直接执行操作——它生成结构化动作请求，消费者应用程序在任何执行之前根据类型契约验证该请求
- 如果请求未通过类型检查（类型错误、缺少权限、工作区错误），操作不会发生——无论大语言模型 (LLM) “认为”什么
从架构上说，这将安全负担从概率性模型转移到确定性类型系统——静态检查而非运行时祈祷。
实践中是什么样子？
作者提供了企业环境中的具体示例：
示例 1 — 工作区隔离：
UpdateCustomerRecord(customerId: CustomerId, fields: CustomerFields)
requires: caller.workspace == customer.workspace如果大语言模型 (LLM) 尝试更新另一个工作区的客户，类型系统在执行前拒绝。
示例 2 — 权限：
SendExternalEmail(to: EmailAddress, body: String)
requires: caller.permissions.includes(SEND_EXTERNAL)模型可以起草完美的邮件——如果用户没有 SEND_EXTERNAL 权限，操作静态失败。
示例 3 — 语义约束：
DeleteRecord(id: RecordId)
requires: record.createdBy == caller || caller.isAdmin即使模型认为合理，也无法删除他人的记录。
为什么这比提示词工程更好？
- 提示词工程依赖于模型阅读并遵守指令。模型总有可能在边界情况下做出不同解释或误触限制。
- 类型契约是编译器级别的检查。不依赖于模型的行为。如果定义正确，所覆盖的错误类别是不可能发生的。
权衡是实现的复杂性。类型系统必须经过精心设计，覆盖真实场景而不过于僵化。论文包含来自多个企业领域（销售、支持、人力资源）的示例，表明这在实践中是可行的。
对 AI 工具构建的影响
对于构建企业 AI 集成的开发者，论文提供了具体的设计模式：
- 明确定义智能体可以执行的所有操作
- 为每个操作编写带有前提条件的类型契约
- 让模型生成结构化动作请求，而不是直接执行
- 验证通过确定性类型检查器，在任何副作用发生之前
该方法与 MCP（模型上下文协议）的趋势一致，MCP 同样提倡结构化工具调用而非自由执行。与 MCP 结合时，结果是分层防御，MCP 和类型契约各自阻止不同类别的错误。
本文是预印本，但想法足够具体，现在构建企业 AI 的团队可以立即应用这些原则——甚至不必等待正式的同行评审发表。
本文由人工智能基于一手来源生成。