谁来定义AI智能体的意图？任务、身份与策略的边界

当智能体开始自主行动，意图成了关键问题

AI智能体（Agent）与传统软件最大的区别在于自主性。传统程序执行的是明确的指令序列，而智能体接收的是一个「任务」——描述要完成的工作，然后自行决定如何达成。这种转变带来一个根本性的问题：谁来定义智能体的意图（intent），以及这个意图的边界在哪里？

原始素材提出的核心命题很直接：一个智能体的任务描述了「要做什么」，但真正的挑战在于如何定义有用的意图，同时保持身份（identity）、资源访问（resource access）和公司策略（company policy）的持续有效。这三者构成了智能体行为的护栏，缺一不可。

任务不等于意图

很多人会把「任务」和「意图」混为一谈，但两者存在微妙而重要的区别。任务是显式的工作描述，比如「整理本季度销售报表并发送给团队」。意图则包含了任务背后的约束、优先级和不可逾越的红线。

如果只给智能体一个任务而不明确意图边界，它可能会用各种意想不到的方式去「完成」任务——访问它本不该触碰的数据源、调用超出授权范围的API，或者绕过合规流程。定义有用的意图，意味着在告诉智能体做什么的同时，也划定了它能用什么身份、访问什么资源、遵守什么规则。

意图定义的三重约束

从素材提炼的框架看，一个健全的意图定义需要同时锚定三个维度：

• 身份（Identity）：智能体以谁的名义行动？它继承了发起者的权限，还是拥有独立的服务身份？这决定了它在系统中的「可信度」。
• 资源访问（Resource Access）：智能体能触碰哪些数据、系统和工具？访问权限必须随任务动态收敛，而非一次性授予全部权限。
• 公司策略（Company Policy）：无论任务如何变化，组织级的合规、安全和治理规则都必须持续生效，不能因为「智能体在自主决策」而被架空。

这三重约束与安全工程中的 POLP（最小权限原则，Principle of Least Privilege） 和 ABAC（基于属性的访问控制，Attribute-Based Access Control） 密切相关。POLP要求任何主体在任何时刻只拥有完成当前任务所必需的最小权限集，超出范围的权限应当被收回或从不授予；ABAC则将"身份""资源""操作""环境上下文"作为动态变量组合判断访问合法性，天然适合智能体权限随任务变化的场景。相比传统的基于角色的访问控制（RBAC），ABAC能更细粒度地表达"这个智能体在执行这类任务时可以访问这个数据集"，而非简单地为智能体分配一个固定角色。这两种机制的结合，构成了文中"情境化授权"的技术基础。

为什么身份和权限必须绑定意图

在人类操作的世界里，权限和身份天然绑定：员工用自己的账号登录，只能访问被授予的资源。但智能体打破了这个假设——它可能代表用户行动，也可能作为独立服务运行，还可能在一个任务链中扮演多个角色。

这就要求身份管理从「静态授权」转向「情境化授权」。智能体在执行某个具体任务时，应当只拥有完成该任务所必需的最小权限集，任务结束后权限即回收。这既是安全原则（最小权限原则）的延伸，也是意图边界的技术落地。

如果放任智能体持有过宽的权限，一旦意图被误解或被恶意提示词劫持（prompt injection），后果可能远超传统软件漏洞——因为智能体有能力主动组合多个操作去达成一个被扭曲的目标。

提示词注入（Prompt Injection） 是当前AI智能体面临的最典型攻击方式之一，值得单独说明。攻击者通过在智能体处理的外部内容（如网页、邮件、文档）中嵌入伪装成指令的文本，诱导智能体偏离原始任务意图，转而执行攻击者预设的操作——例如将敏感数据泄露到外部URL，或冒用当前身份发起未授权请求。与传统SQL注入类似，其本质是数据与指令的边界被打破。正是因为智能体拥有主动组合多步操作的能力，一次成功的提示词注入所能造成的破坏远大于静态程序漏洞：攻击者不需要获得系统的直接访问权，只需污染智能体的"输入环境"即可。这也是为什么最小权限原则在智能体语境下尤为关键——即便意图被劫持，过窄的权限范围能将实际损害控制在最低限度。

策略必须凌驾于任务之上

素材中强调的一个关键点是：公司策略要「保持有效（in force）」。这意味着无论智能体多么智能、任务描述得多么灵活，组织级的策略始终是不可协商的上层约束。

举个例子，即便某个任务在技术上可以通过导出全部客户数据来更高效地完成，如果公司策略禁止批量导出敏感数据，智能体就必须放弃这条路径，转而寻找合规的替代方案。策略不是任务的一部分，而是包裹所有任务的外层容器。

这种设计哲学把「治理」从事后审计前移到了执行时（runtime enforcement）。智能体的每一次资源访问、每一个动作，都应当经过策略引擎的实时校验，而不是依赖开发者在编写任务时的自觉。

运行时策略执行（Runtime Policy Enforcement） 与传统的"设计时合规"形成对比，是理解本文框架的重要背景。传统软件开发中，合规要求通常在设计和编码阶段由开发者内化到业务逻辑中；一旦代码上线，合规性依赖于代码本身的正确性，事后只能通过审计日志发现问题。而运行时执行意味着有一个独立的策略引擎在每次操作发生时实时拦截并校验，无论智能体的任务描述如何生成、由谁生成，策略层都作为外部约束发挥作用。这种架构思路在零信任安全模型（Zero Trust）中已有成熟实践——"永不信任，始终验证"的原则同样适用于智能体的每一次资源请求。对企业而言，这意味着合规责任不再完全依赖AI系统的"自觉"，而是通过架构强制保障。

对企业部署智能体的启示

对于正在评估或部署AI智能体的组织来说，这套框架给出了几点务实的指引：

1. 先定义边界，再定义能力。不要一上来就追求智能体能做多少事，而应先厘清它绝对不能做什么。
2. 意图与身份解耦但可验证。智能体行动时应携带可审计的身份凭证，让每一个操作都能追溯到具体的授权来源。
3. 策略作为运行时护栏。把合规规则编码进执行层，而非仅仅写在文档里。

定义智能体意图的本质，是在自主性与可控性之间寻找平衡。给得太死，智能体沦为普通脚本，失去了价值；给得太松，则埋下安全与合规的隐患。真正有用的意图定义，是让智能体在明确的护栏内自由发挥——既完成工作，又始终受身份、权限与策略的约束。

结语

「谁来定义智能体的意图」这个问题，答案不应是智能体自己，也不应是单一的任务发起者，而是任务、身份、资源和策略共同构成的系统。随着智能体在企业中承担越来越多的自主工作，把意图边界设计清楚，将成为区分「可信智能体」与「失控智能体」的分水岭。

（注：本文基于原始素材的核心观点展开分析，原始素材信息量有限，部分技术细节为基于行业通行实践的合理延伸。）