PES架构：AI Agent需要两个信任域

治理困境

在受监管环境中部署的 Agent 必须同时满足三个目标：

自由漂移（Free drift）：Persona（系统提示词、语气、对话风格）应在无需手动重新部署的情况下演化。

执行可追溯性（Execution traceability）：每个对状态进行变更或访问敏感数据的操作都必须可审计，且具备稳定的身份标识和时间戳。

解耦（Decoupling）：Persona 的变更不应使过去的执行日志失效，也无需对审计追踪进行重新认证。

当尝试在单一进程或信任域中同时满足这三个要求时，最终会以更高的耦合成本重新构建 PES。该论文认为这源于 LLM 的表征不可区分性：仅从模型的内部状态无法判断某项变更是 cosmetic（语气层面）还是 substantive（授权逻辑层面）。因此需要类型化的变更对象、外部门控和稳定的审计锚点。这就是 PES。

PES 将 Agent 拆分为两个组件：

它们之间的契约桥接强制执行以下规则：

审批矩阵（Approval matrix）：执行操作需要明确的授权，而非从 Persona 指令中推断。

DLP 分级（DLP grading）：数据体保留在限制性域中，除非分级异常允许摘要或元数据返回。

身份连续性（Identity continuity）：执行侧维护一个稳定的身份锚点，即便 Persona 演化也不受影响。

状态摘要可以流回 Persona。完整数据体则不会，除非通过明确的 DLP 异常。Persona 无法直接变更执行状态或访问敏感数据，必须跨越桥接。

实现契约

桥接不是网络边界。它可以是同一进程内的 API 契约、消息队列或加密证明层。关键在于执行侧独立验证每个请求，不信任 Persona 的内部状态。

一个最小化的契约如下：

class ExecutionBridge:
    def request_action(
        self,
        action_type: str,
        parameters: dict,
        persona_context: dict,  # for audit, not authorization
        user_identity: str,
    ) -> ExecutionResult:
        # Execution side validates independently
        if not self.approval_matrix.allows(user_identity, action_type):
            return ExecutionResult(status="denied", reason="approval_matrix")

        if not self.dlp.permits_parameters(parameters):
            return ExecutionResult(status="denied", reason="dlp_violation")

        # Execute and log atomically
        result = self.execute(action_type, parameters)
        self.audit_log.append(
            timestamp=now(),
            user=user_identity,
            action=action_type,
            parameters=parameters,
            persona_snapshot=hash(persona_context),  # not the full state
            result=result,
        )

        # Return summary only
        return ExecutionResult(
            status="success",
            summary=result.summary(),
            data_handle=result.handle if self.dlp.permits_handle(result) else None,
        )

Persona 侧发送请求。执行侧做出决定。审计日志同时记录请求和决定，并附上 Persona 上下文的哈希值用于回放，但不记录完整提示词或模型权重。

当 Persona 已发生演化但需要重放旧决策时，有两个选项：

使用当前 Persona 重放：使用审计日志中的参数和用户身份，但让当前 Persona 生成请求。这用于测试新 Persona 是否会做出相同决策。

使用冻结 Persona 重放：使用 Persona 快照哈希从版本控制中检索精确的指令和模型配置，然后重放请求。这用于测试执行侧的验证逻辑是否发生变更。

两者都有用。前者捕获导致行为变化的 Persona 漂移。后者捕获执行侧的回归。

新增故障面

PES 引入了新的故障面：

桥接延迟（Bridge latency）：如果契约桥接是网络调用，每个执行操作都会产生往返开销。对于高频 Agent，这可能成为瓶颈。

审批矩阵漂移（Approval matrix drift）：如果审批矩阵独立于 Persona 演化，可能最终出现 Persona 请求其不再具有执行权限的操作。执行侧会拒绝这些请求，但用户体验会下降。

DLP 误报（DLP false positives）：过于严格的 DLP 规则可能阻断合法数据流，迫使 Persona 绕过桥接或静默失败。

审计日志膨胀（Audit log bloat）：如果 Persona 进行大量探索性请求，审计日志会快速增长。需要制定保留策略和汇总方案。

案例研究

一个受监管的数字员工平台在一个月内实现了 PES，记录了五个架构决策：

Persona 单一归属（Persona singly-homed）：Persona 运行在低信任环境（面向用户的前端）中，无法直接访问生产数据库。

执行侧无形（Execution faceless）：执行侧没有对话记忆或用户特定指令。它根据静态审批矩阵和 DLP 策略验证请求。

Persona 扰动下不重新验证（No re-validation under persona perturbation）：当 Persona 变更时，执行侧不会对过去的操作进行重新验证。审计日志是仅追加的。

硬断言字段上无 Persona 指纹（No persona fingerprint on hard-asserted fields）：审计日志记录 Persona 快照哈希，而非完整提示词或模型权重。这防止了 Persona 漂移使过去的日志失效。

构造性解耦（Decoupling by construction）：一个预分离构建版本中，执行路径通过 omission（无共享状态）与 Persona 解耦，而非通过架构规则。后续的连线变更可能逆转这种隔离。PES 使其成为一个可审计的不变式。

机制检查发现在五种不同模型配置（GPT-4、Claude 3、Llama 3、微调变体）下均无执行侧重新验证。Persona 可以自由漂移而不会使过去的执行日志失效。

何时使用 PES

当以下三个条件同时满足时，PES 适用：

多用户部署（Multi-user deployment）：Agent 为多个具有不同授权级别的用户或角色服务。

执行审计（Execution audit）：法规或合规要求需要对 Agent 实际执行的操作保留不可变记录，而非仅记录其被赋予的指令。

预期 Persona 变动（Expected persona churn）：Agent 的指令、语气或对话风格会频繁演化，无论是通过手动更新还是强化学习。

如果只有其中一或两个条件，更简单的模式就足够。单用户 Agent 可以对整个 Persona-Execution 捆绑包进行版本管理。无审计要求的 Agent 可以让 Persona 和执行侧共享状态。Persona 稳定的 Agent 可以将整个系统视为单一信任域。

何时避免 PES

当你的 Agent 服务于单一用户、没有审计要求，或拥有极少变更的稳定 Persona 时，避免使用 PES。两域拆分会增加延迟和运维开销。如果你可以将整个 Agent 作为单元进行版本管理，就采用那种方式。

运维注意事项

注意审批矩阵漂移、DLP 误报和审计日志膨胀。这些是运维问题，而非架构问题，但如果不提前规划，可能使 PES 无法运作。你需要工具来可视化审批矩阵、测试 DLP 规则，以及汇总审计日志。

---

Persona-Execution Separation: An Architecture Pattern for Evolving LLM Agents under Execution Audit (arXiv:2608.27427v1)