Perplexity：AI智能体治理本质是工程问题

智能体治理为何被定义为工程问题

Perplexity 近日抛出一个鲜明的观点：AI 智能体（Agent）的治理，本质上是一个工程问题，而非仅靠政策条款或事后约束就能解决的抽象议题。随着自主智能体被越来越多地嵌入搜索、浏览和任务执行等真实产品场景，如何确保它们的行为安全、可控、可审计，正从理论讨论走向实际的系统设计。

这一表态背后的逻辑值得关注。过去关于 AI 安全的讨论常停留在伦理框架、合规声明层面，而 Perplexity 强调的是把安全约束直接写进基础设施、执行框架（harnesses）与工具链之中——也就是让安全成为系统的默认属性，而不是外挂的补丁。

三层防护：基础设施、Harness 与工具

Perplexity 披露其安全机制覆盖了三个层面，这也勾勒出一个值得借鉴的智能体安全架构思路。

基础设施层

在底层基础设施中内置安全约束，意味着智能体在运行环境层面就受到边界限制。无论上层逻辑如何调用，底层都能提供一道统一、难以绕过的防线。这种设计避免了安全策略分散在各个应用中、难以统一维护的问题。

执行框架（Harness）层

Harness 可以理解为智能体与模型、工具之间的调度与约束层。把安全防护放在这一层，意味着在智能体决策和行动的关键环节加入检查点，对其可执行的操作范围进行约束。这一层往往是智能体真正"做出动作"的地方，也因此是治理的核心战场。

Harness 这一概念来自软件测试与自动化领域，原指用于驱动和约束被测系统行为的"测试脚手架"。在 AI 智能体语境中，它被借用来描述一套包裹在模型与外部动作之间的中间层框架，负责接收模型的输出意图、解析指令、分配工具调用、并在实际执行前进行合规检查。与直接调用 API 的扁平架构不同，Harness 层将"决策"与"执行"解耦，使开发者可以在不修改底层模型的情况下，插入权限校验、行为审计、速率限制等安全逻辑。OpenAI 的 Assistants API、Anthropic 的 Claude tool use 框架以及 LangChain 的 Agent Executor，都可视为不同形态的 Harness 实现。这一层之所以被视为治理的核心战场，是因为它处于"模型想做什么"与"系统实际允许做什么"之间的临界点，是拦截高风险行为的最后一道可编程防线。

工具层

智能体通过调用各种工具（搜索、浏览、数据访问等）与外部世界交互。在工具层面设置权限和边界，能够精细化控制智能体"能碰什么、不能碰什么"，降低越权操作或误用的风险。

把安全嵌入产品，而非停留在声明

Perplexity 特别强调，这些防护机制已经在其产品中实际投入使用（put them to work across our products），而非仅停留在实验室或白皮书阶段。对于一家以 AI 搜索和智能问答为核心产品的公司而言，智能体需要频繁地浏览网页、执行多步任务，安全失控的代价可能直接体现在用户体验和数据安全上。

这种"工程先行"的治理思路，与当前行业中部分公司偏重对外发布安全原则、却缺乏具体落地机制的做法形成对比。将治理拆解为可实现、可测试、可迭代的工程模块，意味着安全能力可以像其他功能一样被持续改进和验证。

对行业的启示

智能体正在成为 AI 应用的新形态，它们不再只是回答问题，而是能够自主规划并执行一系列操作。能力越强，潜在风险越大。Perplexity 的表态释放出一个信号：随着智能体走向大规模部署，安全治理必须从概念共识转化为具体的系统设计实践。

对开发者和企业而言，几点思路具有参考价值：安全约束应尽可能下沉到基础设施和调度层，减少对单点应用自觉的依赖；工具调用权限需要精细化管理；安全机制应当可在真实产品中验证并持续迭代。

需要说明的是，Perplexity 此次仅以简短声明和链接形式对外分享，更详细的技术实现细节需参考其官方发布的完整文档。本文基于其公开表态进行解读，具体机制有待进一步验证。

智能体安全治理的工程化趋势，与学术界提出的"最小权限原则"（Principle of Least Privilege）和"纵深防御"（Defense in Depth）等经典安全设计思想一脉相承。最小权限原则要求系统中的每个组件只被授予完成其任务所必需的最低限度权限，直接对应工具层的精细化权限管理；纵深防御则主张在多个独立层次上叠加安全控制，与文中基础设施、Harness、工具三层架构的逻辑高度吻合。此外，能够可审计（auditable）也是智能体治理的关键属性——当智能体执行了一系列多步操作后，系统需要保留足够的日志与追踪信息，以便在出现问题时还原决策链路、定位责任边界。这对企业级部署尤为重要，也是当前多数开源智能体框架尚待完善的环节。