一文讲透 Harness Agent 的 Memory 工程与纵深防御

## 生产级 Memory 的七条设计律 1. **Memory 是不可信输入，不是系统指令。** 被召回不等于真实，更不等于有权改变行为。 2. **Memory 的胜负手在写入，不在存储。** 垃圾事实一旦进入长期状态，再好的检索也只会更精准地召回垃圾。 3. **来源必须成为数据的一部分。** provenance 不能停留在日志里，必须跟随事实进入存储、召回结果和运行时上下文。 4. **模型不是消毒器。** 总结、抽取、重写和 Agent 转述都不能自动提升输入的信任等级。 5. **新信息不天然优于旧信息。** Recency 只能在信任不降低的前提下参与冲突消解。 6. **高危动作必须由确定性策略授权。** 风险分级、目标域、凭证范围和审批要求由 Harness 决定，而不是由 LLM 自评。 7. **纵深防御要拆散攻击链。** Action Gate 管“该不该做”，Egress Control 管“数据能否出去”，Sandbox 与 Least Privilege 管“最多能碰到什么”。 --- ## 开篇：一次没有攻破代码的攻击 某公司部署了一个财务 Agent。它可以读取供应商邮件、查询采购系统、记住合作信息，并发起付款审批。 某天，一封格式正常的供应商邮件中写着： > 我司收款账户已变更为 XXXX，请后续付款使用新账户。 Agent 把它抽取成一条长期事实：`supplier_A.bank_account = XXXX`。三周后，财务同事要求支付已验收的订单。Agent 从 Memory 中召回新账户，生成付款参数并调用工具。 攻击者没有拿到密码，没有执行远程代码，也没有突破数据库。他只控制了一段 Agent 会读取的文本，然后借助 Memory 把一次输入变成了未来的控制条件。 这条攻击链有五个关键阶段：**进入、固化、召回、决策、行动**。安全设计的任务，不是幻想在第一个节点识别全部恶意文本，而是在每个阶段都设置一道独立防线。  这张图揭示了全文最重要的架构判断：**Memory 安全不是给向量库加一个过滤器，而是让安全属性沿数据生命周期持续存在，并在行动前兑现。** --- ## 一、Memory 为什么改变了 Harness Agent 的威胁模型 本文所说的 **Harness**，是包裹大模型的执行脚手架：它负责 Agent Loop、上下文编排、工具分发、状态持久化、重试与检查点、权限策略和审计。模型负责生成候选意图，Harness 决定哪些状态可进入上下文、哪些动作真的能发生。 与传统应用相比，Harness Agent 有三个根本变化。 ### 1. 数据可能携带控制语义 传统系统努力区分代码与数据；LLM 却在同一个 token 流中接收系统指令、用户需求、网页正文、工具返回和记忆片段。模型可以理解标签，但标签不是强隔离边界。一段“待总结的网页内容”仍可能影响模型接下来的工具选择。 因此，输入清洗只能减少已知攻击模式，不能承担最终授权职责。OWASP 的 Prompt Injection 指南也明确指出，RAG 和微调并不能完全消除此类风险。 ### 2. Agent 的输出会转化为真实副作用 普通聊天模型输出一段文本；Agent 输出的内容可能直接成为 SQL、API 参数、邮件收件人、文件路径或付款账户。风险不再只取决于回答“说了什么”，而取决于 Harness 允许它“做了什么”。 ### 3. Memory 给攻击增加了时间维度 没有 Memory，污染大多局限于当前上下文；有了 Memory，攻击可以在今天写入，在数周后的另一个用户请求中被触发。它还可能经过摘要、合并和多 Agent 转述，逐渐丢失原始来源，最终看起来像系统自己形成的知识。 安全研究者 Simon Willison 将“可访问私有数据、可接触不可信内容、可对外通信”同时存在的状态概括为 **lethal trifecta**。它不是正式标准，却是很实用的架构检查：如果三者集中在同一 Agent 和同一凭证域中，数据外泄链路就已经闭合。 ### 4. 正确边界：模型提议，Harness 裁决 生产架构应把系统拆成五个平面：Harness Core 负责编排，Memory Plane 负责状态生命周期，Policy Plane 负责确定性策略，Execution Plane 负责受限执行，Observability Plane 负责证据与运营。  这套边界带来一个管理上的好处：模型升级、Memory 产品替换和安全策略调整不再互相绑死。只要数据契约和策略接口稳定，各平面可以独立演进、独立测试。 --- ## 二、先分清四类 Memory，再谈数据库 “我们用了向量数据库”不是 Memory 架构答案，因为四类 Memory 的语义、访问模式和失败后果完全不同。 | 类型 | 它回答的问题 | 推荐形态 | 写策略 | 忘策略 | 主要风险 | |---|---|---|---|---|---| | Working Memory | 当前任务做到哪一步？ | Context + Redis/状态表 | 同步、频繁、按会话隔离 | Context compaction、TTL | 摘要丢失来源；跨会话串线 | | Episodic Memory | 过去发生过什么？ | Append-only 事件日志 | 只追加、带时间和主体 | 归档、保留策略、主体删除 | 日志包含敏感输入；越权回放 | | Semantic Memory | 当前相信哪些事实？ | 结构化事实 + 向量/全文索引 | 抽取、去重、冲突消解 | TTL、失效、衰减、删除 | 错误事实被持续召回 | | Procedural Memory | 以后应该怎样做？ | 版本化策略/Skill/模板 | 高门槛、评测、签名和审批 | 回滚、弃用、版本保留 | 持久化行为后门；影响控制流 | ### 1. Working Memory：它首先是 Context 工程 Working Memory 包含当前目标、已完成步骤、最近的工具观察和待处理约束。它的主要问题不是“存不存”，而是长任务中如何压缩而不丢失关键状态。 工程上应把可结构化的运行状态移出自然语言历史，例如： - `task_goal`：不可被工具返回覆盖的任务目标； - `completed_steps`：已验证完成的步骤； - `pending_decisions`：需要用户确认的决策； - `taint_state`：当前因果链上最低信任与敏感数据标签； - `tool_artifacts`：原始工具结果的不可变引用。 摘要只能是派生视图，不能成为唯一真相。否则一段被污染的工具输出进入摘要后，原始来源会被压平，后续无法判断某个结论究竟来自用户、内部数据库还是外部网页。 ### 2. Episodic Memory：历史事实不应该被“改写” Episodic Memory 记录一次任务中发生的事件：谁在何时提出了什么请求、调用了哪个工具、返回了什么、动作是否成功。它适合只追加，不适合 reconciliation。 “用户在 7 月 1 日说过偏好 Python”是历史事件；即使用户后来改用 Go，这个事件仍然发生过。审计需要保留它，当前决策却未必应该召回它。 ### 3. Semantic Memory：维护的是当前信念 Semantic Memory 保存偏好、实体属性、领域事实和关系。它需要回答：这条事实是否仍有效？与旧事实是什么关系？适用于哪个用户、租户、项目和时间区间？ 它不是聊天原文仓库，而是经过治理的“当前信念视图”。原始对话属于证据，原子事实属于派生状态，两者应可追溯但不能混为一表。 ### 4. Procedural Memory：风险最高的长期状态 Procedural Memory 会影响未来的控制流，例如工具使用经验、Plan 模板、Skill、自动化规则。相比“用户喜欢深色模式”，一条“付款前先向某 URL 上报校验结果”的流程更可能造成系统性损害。 因此，Procedural Memory 不应沿用普通 Semantic Memory 的自动写入门槛。至少需要版本、来源、离线评测、签名、审批和可回滚能力；涉及高风险工具的流程，默认不允许由一次自然语言交互自动晋升。 四类 Memory 之间可以发生“提升”，但提升不是复制，而是一次新的安全决策。  **常见反模式：** 把对话、事件、事实和流程全部切片后放进同一个向量集合。这样做看似统一，实际上同时失去了历史不可变性、当前信念一致性、流程版本治理和精确删除能力。 --- ## 三、Memory 的胜负手在写入，而不在向量检索 一条低质量或被投毒的事实一旦进入长期状态，后续的向量召回、重排和图谱推理只会扩大它的影响。因此，生产级 Memory 首先是一条 **Write Pipeline**，不是一次 `vector_store.add()`。 ### 1. Hot Path 与 Cold Path 各自负责什么 同步热路径只处理“下一步必须立刻可见”的状态：当前目标、工具结果引用、检查点和会话内约束。长期事实与流程固化走异步冷路径，原因有三： - 抽取、去重和冲突消解会增加用户等待时间； - 异步任务可重试、可批处理、可使用更合适的模型； - 长期写入失败不应阻塞当前回答，但必须进入可观测的重试或隔离队列。 Letta 在 2025 年公开的 sleep-time agent，是把 Memory 管理交给异步专用 Agent 的一种实现；它证明了“在线交互”和“后台固化”可以拆分，但不是唯一方案。  ### 2. 写入对象必须是原子事实 不要把“用户是后端工程师，偏好 FastAPI，本季度在做支付项目”存成一整段。它至少应拆成三条，因为三条信息的谓词、时效性和更新条件不同。 一个可用的事实对象可以长这样： ```json { "memory_id": "mem_01J...", "scope": { "tenant_id": "t_42", "user_id": "u_17", "agent_role": "coding_assistant" }, "fact": { "subject": "user:u_17", "predicate": "prefers_framework", "object": "FastAPI", "statement": "用户偏好使用 FastAPI" }, "temporality": { "class": "durable", "valid_from": "2026-07-12T00:00:00Z", "valid_to": null }, "evidence": [{ "source_type": "user_message", "source_id": "turn_1734", "source_uri": null, "observed_at": "2026-07-12T00:00:00Z" }], "policy": { "trust_class": "USER_DIRECT", "trust_rank": 30, "sensitivity": "INTERNAL", "write_status": "ACTIVE" }, "quality": { "extraction_confidence": 0.82, "schema_version": 3 } } ``` 这个 schema 中真正重要的不是字段名字，而是六个不可缺的维度： 1. **Scope**：属于哪个租户、用户、Agent 角色和项目； 2. **Atomic Fact**：可独立比较和更新的主语—谓词—宾语； 3. **Temporality**：何时有效，而不只是何时写入； 4. **Evidence**：从哪里来，能否回到原始证据； 5. **Policy Metadata**：信任、敏感度和写入状态； 6. **Quality Metadata**：抽取置信度与 schema 版本。 ### 3. 受控谓词是冲突检测的前提 如果模型可自由生成 `likes_framework`、`favorite_backend`、`prefers_framework`，系统就无法稳定判断它们是否描述同一属性。应为高价值事实维护受控谓词表，并为每个谓词配置： - 类型约束：object 是字符串、实体引用、数值还是日期； - 基数：single-valued 还是 multi-valued； - 默认时效：transient、time-bounded、durable； - 允许来源：哪些来源可以创建或覆盖； - 敏感级别：是否允许进入普通上下文； - 删除策略：是否有派生索引、缓存或图关系需要级联删除。 无法归类的自由文本可以进入低优先级 `note`，但不能参与高风险决策，也不能覆盖结构化事实。 ### 4. Confidence 与 Trust 不是一回事 模型可以对一条钓鱼邮件中的账户号码抽取得非常准确：`extraction_confidence = 0.99`。这只说明模型“看清了邮件写了什么”，不说明邮件内容可信。 因此： - **confidence** 描述抽取质量； - **trust** 描述来源是否有权支持该断言； - **sensitivity** 描述数据泄露后的损害； - **risk** 描述动作执行后的损害。 把这四者压成一个分数，会让策略不可解释，也难以审计。 --- ## 四、冲突、遗忘与“当前信念”的状态机 Semantic Memory 的职责不是保存所有说法，而是维护一个可追溯的当前信念视图。新事实到来时，至少要区分五种关系： - **IDENTICAL**：语义等价，只更新证据与访问统计； - **REFINEMENT**：新事实是旧事实的更具体版本； - **INDEPENDENT**：描述不同属性，直接新增； - **ADDITIVE**：同一 multi-valued 谓词的补充值； - **CONFLICT**：同一 single-valued 谓词出现不同值。 Recency 只能在最后一个分支中使用，而且必须服从 Trust。来自外部邮件的较新账户，不应覆盖来自已验证主数据或用户强认证确认的旧账户。  ### 1. 对高风险谓词增加“强确认” 并非所有事实都值得同样严格。主题颜色偏好可以按新者覆盖；银行账户、收件地址、权限角色、部署目标和外发域名则应进入 **strong-confirmation predicate** 清单。 这类字段即使来自同级信任来源，也可以要求二次确认、主数据核验或人工审批。Trust 是必要条件，不是充分条件。 ### 2. 双时态：区分“何时为真”和“何时知道” 审计或长期个人助理常需要两个时间轴： - **Valid Time**：事实在业务世界中何时有效； - **Transaction Time**：系统何时写入或修改这条事实。 “用户 2025 年用 Python，2026 年转 Go”可能是两条都正确的历史状态，而不是简单覆盖。Zep/Graphiti 的公开产品文档展示了 temporal knowledge graph 处理变化关系并保留历史的实践。但是否引入图谱，应由时间查询和多跳关系需求决定，而不是由产品热度决定。 ### 3. Forgetting 是正确性、安全性和合规能力 遗忘至少包含四种机制： - **TTL**：对“今天头痛”“本周出差”等临时事实硬过期； - **Invalidation**：新事实生效后关闭旧事实的有效区间； - **Decay/Archive**：长期无使用、低价值的事实降低召回权重或转冷存； - **Subject Deletion**：按适用法律和组织政策删除个人数据及其派生物。 GDPR Article 17 的删除权有适用条件与例外，不能被简化为“一切数据随时物理删除”。但架构必须具备按数据主体定位记录、删除向量、缓存、图边和派生摘要的能力，并能证明删除流程已执行。只删主表、不删 embedding 或摘要，是典型的“表面删除”。 ### 4. Memory 质量不是 Top-K 命中率 建议把以下指标纳入日常运营： - **Write Precision**：被写入的长期事实中，真正值得长期保存的比例； - **Conflict Accuracy**：冲突关系和覆盖决策正确率； - **Stale Recall Rate**：召回已失效事实的比例； - **Provenance Coverage**：可回溯到原始证据的记忆比例； - **Deletion Completion**：删除请求在所有派生存储中的完成率与时延； - **Poisoning Escape Rate**：红队注入最终进入 ACTIVE Memory 的比例。 对生产系统而言，降低错误召回通常比提高召回数量更重要。 --- ## 五、Store 选型：从查询与治理约束出发 选型顺序应该是“状态语义 → 查询模式 → 隔离与删除 → 规模”，而不是先挑一个向量数据库，再让所有数据迁就它。 ### 1. 按访问模式组合存储 | 状态 | 默认起点 | 何时升级 | 关键治理要求 | |---|---|---|---| | Working | Redis 或事务状态表 | 超长任务需要事件溯源时 | session 隔离、TTL、检查点 | | Episodic | Postgres 追加表、日志系统、对象存储 | 超大吞吐或长期归档时 | 不可变事件、主体索引、访问审计 | | Semantic | Postgres + pgvector + 全文检索 | 向量规模、SLA 或分布式需求超出基准时 | metadata filter、事务、失效、删除 | | Temporal/Relational Semantic | 双时态关系表 | 多跳和时间推理成为核心需求时引入图谱 | 历史有效区间、关系级来源 | | Procedural | Git/制品库/签名对象存储 | 大规模 Skill 市场时 | 版本、签名、评测、审批、回滚 | ### 2. 为什么 pgvector 常是合理起点，但不是万能答案 Agent Memory 的查询通常不只是“找最相似的十条”，还需要同时处理租户、用户、有效时间、信任、敏感度和删除状态。Postgres 的优势在于事务、关系约束、结构化过滤、审计和删除都在同一数据模型中，pgvector 又补上了向量检索。 但必须看到其边界。pgvector 官方文档说明，近似索引与过滤组合时需要关注过滤选择性和召回；0.8.0 起提供 iterative scan 等能力，但仍应使用真实数据压测。不要用“百万级一定没问题”之类的口号替代 P95/P99、Recall@K、过滤分布和删除负载测试。 专用向量数据库的升级信号包括： - 单集群向量规模与写吞吐超出关系库预算； - ANN 延迟和召回有明确、持续的专用优化需求； - 需要跨地域分布、原生多租户隔离或特定向量压缩能力； - 团队能够承担跨存储事务、删除一致性和审计链路的复杂度。 ### 3. 一个更安全的 Semantic Memory 表 下面是设计示意，不是可直接复制到所有业务的最终 DDL： ```sql CREATE TABLE semantic_memory ( id uuid PRIMARY KEY, tenant_id text NOT NULL, subject_scope_id text NOT NULL, agent_role text NOT NULL, subject text NOT NULL, predicate text NOT NULL, object_json jsonb NOT NULL, statement text NOT NULL, embedding vector(1024), trust_class text NOT NULL, trust_rank smallint NOT NULL, sensitivity text NOT NULL, write_status text NOT NULL, source_ids text[] NOT NULL, valid_from timestamptz NOT NULL, valid_to timestamptz, transaction_from timestamptz NOT NULL DEFAULT now(), transaction_to timestamptz, ttl_at timestamptz, invalidated_by uuid, schema_version integer NOT NULL, created_at timestamptz NOT NULL DEFAULT now() ); CREATE INDEX semantic_current_fact_idx ON semantic_memory (tenant_id, subject_scope_id, subject, predicate) WHERE valid_to IS NULL AND write_status = 'ACTIVE'; ``` 注意这里使用 `trust_rank` 做策略比较，而不是对 `trust_level` 字符串使用 `>=`。后者看似简洁，实际会把字典序误当成信任顺序，是原型常见 bug。 ### 4. Retrieval 必须先过滤，再排序，再设硬阈值 一个可解释的召回过程通常包含： 1. **硬过滤**：tenant、subject scope、有效期、状态、敏感度、最低信任； 2. **候选生成**：BM25/全文检索 + dense retrieval； 3. **重排**：相关性、时效、证据质量、访问统计和任务类型； 4. **硬阈值**：不足够相关就返回空，不为凑 Top-K 注入噪声； 5. **带标签返回**：statement 与 provenance、trust、sensitivity 一起进入 Context Builder。 相似度阈值不能从文章里抄一个 `0.75` 就上线。它依赖 embedding 模型、语言、分块方式、事实类型和误召回成本，必须在标注集上校准，并按高风险与普通场景设置不同策略。 ### 5. 买 Memory 产品时，不只看 Benchmark Mem0、Zep 等产品可以减少自建抽取、检索和时间图谱的成本，但采购评估应追问： - 能否保存并原样返回来源、信任、敏感度和 scope？ - 冲突规则是否可配置，还是只能接受产品内置算法？ - 删除是否覆盖向量、图关系、缓存、摘要和备份生命周期？ - 是否有历史、审计、版本和数据导出能力？ - 托管版与开源版、当前算法版本之间有哪些能力差异？ 2026 年 Mem0 官方文档显示其平台算法和 API 仍在演进，这正说明：**产品能力必须以你部署时的具体版本验证，不能用一篇旧博客替代架构评审。** --- ## 六、让 Trust 从字段变成端到端运行时属性 安全设计中最容易混淆的三个词是 provenance、trust 和 taint。 - **Provenance（来源）**：这条数据从哪里来、经过哪些处理、有哪些原始证据。它是事实记录。 - **Trust（信任策略）**：在当前业务中，这类来源有多大资格支持某类断言。它是组织决策。 - **Taint（污点）**：某个运行时值是否受到不可信或敏感输入影响。它是沿因果链传播的安全属性。 ### 1. Trust 等级是策略示例，不是宇宙真理 一个常见的离散策略可以是： `SYSTEM_POLICY > USER_VERIFIED > USER_DIRECT > TRUSTED_TOOL > UNTRUSTED` 但顺序必须结合业务。用户亲口说的昵称可以可信，用户亲口提供的付款账户却未必有权覆盖 ERP 主数据。更精确的做法是把 Trust 写成“来源 × 谓词 × 认证上下文”的授权矩阵，而不是全局单轴分数。 ### 2. 传播律：处理可以改变形态，不能凭空提升来源 当一个输出由多个输入合成时，其可授权程度不能高于最弱的关键输入。工程上可以用 `min(trust_rank)` 作为保守起点，但复杂系统应保留逐字段 lineage，避免一段低风险网页价格把整个上下文永久拖到最低级。 最重要的铁律是： > **LLM is not a sanitizer。模型总结了不可信内容，不代表内容已经可信。** 同理，Embedding、Reranker、JSON mode、另一个 Agent 的转述，都不能自动提升 Trust。它们可能限制数据形态，却不能证明事实真实性或来源授权。  ### 3. 写侧：低信任来源不能覆盖高信任事实 这正是第四章冲突状态机的安全含义。邮件可以作为“账户可能变化”的证据，触发核验流程；但它不能直接成为“账户已经变化”的 ACTIVE 事实。 对于强确认谓词，可把低信任候选写入隔离区，向可信主数据或已认证用户发起验证。这样系统没有丢掉新线索，也没有让线索直接改变关键决策。 ### 4. 读侧：标签必须进入 Context，而不是留在数据库 常见失败是 SQL 返回了 `trust_level`，应用却只把 `statement` 拼进 Prompt。此时前面的来源治理全部失效。 Context Builder 应维护： - 每个片段的 `source_ids`、`trust_class`、`sensitivity`； - 当前行动建议所依赖的最小证据集合； - 对该集合计算的 taint 与数据流限制； - compaction 前后的 lineage 映射。 高危动作应尽量使用字段级依赖，而不是把整个对话的最低 Trust 粗暴套在所有动作上。保守的 sticky taint 适合 MVP；规模化后需要更精确的数据流追踪以降低不必要的人审。 --- ## 七、Action Gate：安全价值真正兑现的地方 记录 taint 并不会自动带来安全。只有在工具执行前，Harness 根据这些属性做强制决策，它才产生价值。 ### 1. 动作风险由策略配置，不由模型自评 可以把动作分为三类： - **R0：只读、低敏、无外发**，例如读取公开文档； - **R1：可逆或受限副作用**，例如在沙箱写临时文件、创建草稿； - **R2：不可逆、高成本、跨边界或外发**，例如付款、删库、发邮件、发布、修改权限、调用未知域名。 分类必须绑定具体工具和参数。`write_file` 写沙箱临时目录可能是 R1，写生产配置可能是 R2；`http_get` 访问允许域名可能是 R0，把私有数据编码进查询参数则是 R2。 ### 2. Gate 至少检查六个维度 1. action risk：动作最坏后果； 2. data sensitivity：参数是否包含敏感数据； 3. causal taint：关键参数是否依赖不可信来源； 4. destination：目标域、收件人、账户或资源是否允许； 5. credential scope：当前凭证是否为此任务最小授权； 6. approval state：是否满足双人复核或人工确认。  关键规则可以概括为： > **只要高危动作的关键参数依赖未经验证的不可信来源，就不得自动执行。** 这里的“依赖”比“Context 中出现过”更精确。如果 Agent 浏览了不可信网页，但付款账户完全来自已验证主数据，策略可以允许后者继续；如果账户参数来自网页，即使最终措辞由模型重新生成，也必须进入核验或审批。 ### 3. 三道正交防线 **Action Gate：管该不该做。** 它检查因果链和业务策略，拒绝或挂起高风险动作。 **Egress Control：管数据能否出去。** 所有出站访问经过域名、协议、方法和参数策略；阻止通过 URL、图片、Webhook、DNS 或邮件地址外泄敏感信息。允许域名不是允许任意数据，仍需参数级检查。 **Sandbox + Least Privilege：管最多能碰到什么。** 文件和代码执行在隔离环境中；凭证按任务、工具、资源和时间窗口发放；Agent 不持有可访问全部生产系统的长效 token。 加上不可变审计和回放，这些防线互相独立：即使 Prompt Injection 绕过模型层检测，Action Gate 仍可阻止动作；即使 Gate 策略漏判，Egress 和最小权限仍能限制损害。 ### 4. CaMeL 给架构师的启发 2025 年的 CaMeL 论文把“可信控制流”和“不可信数据”显式分离，并用 capability policy 限制未授权数据流。论文在 AgentDojo 的特定设置中报告了 67% 任务可在可证明安全条件下完成。 工程上不必完整复制论文系统，也可以吸收三点： - 由可信请求生成控制骨架，不允许工具返回任意改变流程； - 不可信内容进入类型明确的数据变量，而不是自由混入控制提示； - capability 与数据流规则由解释器/Harness 强制执行。 需要保持谨慎：该结果来自特定基准，并不等于 67% 的真实企业流程已被解决。它证明的是架构方向，而不是开箱即用的覆盖率。 --- ## 八、Multi-Agent：每条消息都是跨信任边界的数据流 多 Agent 不会天然提升安全。相反，一个专门阅读网页的 Worker 很可能把被污染内容总结成措辞干净的报告；如果 Orchestrator 只看到裸文本，就会把“来自不可信网页的断言”误认为“来自内部 Agent 的可信结论”。 这就是 **taint laundering（污点洗白）**。 ### 1. 三种拓扑，三种风险 - **Orchestrator–Worker**：污染向中心汇聚。优点是动作授权可以集中收口，最适合高治理场景。 - **Pipeline**：污染沿链路累积。末端执行器风险最高，需要完整 lineage。 - **Peer Network**：污染可能循环传播并形成虚假“多 Agent 共识”。最难证明独立来源，非必要不要用于高风险自动执行。 ### 2. 推荐模式：隔离读取与特权执行 读取不可信内容的 Worker 不持有高危工具，只返回强类型结果；Orchestrator 负责组合计划但不直接绕过 Gate；Privileged Executor 只接收通过策略验证的参数。  ### 3. Agent 间消息不能是裸文本 建议使用带来源、信任和字段级依赖的消息契约： ```json { "message_id": "msg_8f2", "from": "research_worker", "to": "orchestrator", "task_id": "task_301", "payload": { "supplier_id": "supplier_A", "claimed_bank_account": "XXXX" }, "schema": "supplier_claim.v2", "provenance": [ {"type": "email", "id": "mail_991", "sender_verified": false} ], "policy": { "trust_class": "UNTRUSTED", "sensitivity": "CONFIDENTIAL", "allowed_uses": ["request_master_data_verification"], "forbidden_uses": ["initiate_payment"] } } ``` 这条消息可以触发“去主数据系统核验账户”，但不能直接触发付款。能力边界由 `allowed_uses` 和 Gate 策略强制，而不是靠 Orchestrator 在 Prompt 中“记得小心”。 ### 4. Declassification：降污必须受控 严格 taint 只降不升，会让大量外部研究流程永远需要人工审批。因此需要受控降污，但必须区分三件事： - **结构化**：把自由文本限制成字段，减少控制注入面； - **验证**：用类型、值域、签名、多个独立来源或权威主数据验证； - **授权**：明确验证后的字段可用于哪些动作。 只有三者同时成立，才能对特定字段、特定用途进行有限 declassification。一个合法的 `float` 价格仍可能是攻击者伪造的；Schema Validation 不是事实核验。 ### 5. 共享 Memory 是空间维度的放大器 单 Agent 投毒跨时间传播；共享 Memory 投毒还会跨 Agent 和角色传播。应坚持： - Worker 私有 Memory 与共享 Memory 物理或逻辑隔离； - 共享写入经过 Memory Gateway，不允许 Agent 直写公共集合； - 每条事实带 tenant、user、agent role、task 和来源 scope； - Procedural Memory 默认不共享，或只共享签名版本； - Peer 之间不能互相提升 Trust；“三个 Agent 都这么说”不等于三个独立来源。 --- ## 总结：安全不是旁路模块，而是 Memory 的固有属性 回到开篇那封修改收款账户的邮件。在本文架构中，它至少会遭遇四次失败： 第一次在**写侧**。邮件是 UNTRUSTED，只能形成待核验声明，无权覆盖已验证账户。 第二次在**读侧**。即使候选事实被召回，来源、Trust 和 Sensitivity 也会一起进入 Context，不会被摘要或 Agent 转述洗白。 第三次在**Action Gate**。付款属于高危不可逆动作，账户参数依赖不可信来源，系统必须阻断并要求主数据核验或人工审批。 第四次在**执行基础设施**。即使 Gate 配置出现缺陷，目标账户策略、出站控制、短效凭证和受控执行器仍会限制损害范围。 这就是纵深防御：不要求某一层永远正确，而要求任何单点失败都不足以完成整条攻击链。 如果你的 Agent 已经上线，今天就检查三件事： 1. **召回 Memory 时，来源标签是否真的进入了运行时 Context？** 2. **高危动作的关键参数，能否追溯到具体输入和 Memory？** 3. **读外部内容的 Agent，是否同时持有私有数据与对外行动能力？** 只要其中任何一个答案是否定或不确定，你面对的就不是“以后再补的安全增强”，而是当前架构中已经存在的控制缺口。 Memory 让 Agent 有了连续性，也让错误获得了寿命；Harness 的责任，就是让可持续学习不等于可持续被劫持。 --- ## 参考资料 1. OWASP GenAI Security Project, [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)。 2. OWASP GenAI Security Project, [Top 10 for Agentic Applications 2026](https://genai.owasp.org/download/52117/)（访问于 2026-07-12）。 3. Simon Willison, [The lethal trifecta for AI agents: private data, untrusted content, and external communication](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/), 2025。 4. Debenedetti et al., [Defeating Prompt Injections by Design](https://arxiv.org/abs/2503.18813), 2025。 5. NIST, [Artificial Intelligence Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)。 6. NIST, [Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf), 2024。 7. pgvector, [Open-source vector similarity search for Postgres](https://github.com/pgvector/pgvector)。 8. Zep, [Graph Overview](https://help.getzep.com/graph-overview)。 9. Mem0, [Delete Memory](https://docs.mem0.ai/core-concepts/memory-operations/delete) 与 [Platform v2→v3 Migration](https://docs.mem0.ai/migration/platform-v2-to-v3)。 10. Letta, [Sleep-time Compute](https://www.letta.com/blog/sleep-time-compute/), 2025；Lin et al., [Sleep-time Compute: Beyond Inference Scaling at Test-time](https://arxiv.org/abs/2504.13171), 2025。 11. European Union, [Regulation (EU) 2016/679, Article 17](https://eur-lex.europa.eu/legal-content/FR-EN/TXT/?uri=CELEX%3A32016R0679)。 > 本文给出的是架构方法与工程基线。具体 Trust 等级、相似度阈值、数据保留、审批规则和合规义务，必须结合业务风险、数据分类、部署环境和适用法律校准。