系列第 20 篇（终篇）。主文档见 智能体上下文工程实现.md。
agent 系统天然处理大量个人信息：用户对话、代码（含 secret）、工具结果（含 PII）、记忆（含偏好和身份信息）。这一篇讲在 GDPR / CCPA / 企业数据政策约束下，上下文工程必须额外考虑的维度。
0. 隐私是默认的工程约束，不是事后补丁
很多 agent 团队把隐私当作"上线前补一下"的合规项。实际上隐私决策影响：
- 存什么（Memory、日志、cache）
- 存多久（保留期）
- 存哪里（区域、加密）
- 谁能看（访问控制）
- 怎么删（用户权利响应）
- 如何审计（数据流转可追溯）
这些都直接影响上下文工程的实现 —— 设计 Memory 时不考虑删除权，未来重写代价巨大。
1. agent 系统的数据敏感度地图
不同位置的数据敏感度：
| 位置 | 典型内容 | 敏感度 |
|---|---|---|
| 用户消息 | 问题、想法、偶尔含 PII | 高 |
| 工具结果 | 代码、log、网页 | 中-高（代码可能含 secret） |
| Memory | 用户偏好、项目信息 | 中-高 |
| Plan / Todo | 任务描述 | 中 |
| Cache（API 侧） | 完整 prompt 前缀 | 高 |
| 日志 | 完整对话 + 工具结果 | 极高 |
| 后台任务输出 | 工具完整 stdout | 极高 |
| extended thinking | 模型推理（可能含敏感） | 高 |
日志和 cache 是最容易被忽视的高敏感点。它们不是"用户看到的内容"，但实际可能比用户消息更敏感（含完整工具输出）。
2. PII 和 secret 的检测与处理
2.1 常见的隐式泄漏
# 用户对话
"我的 API key 是 sk-ant-api03-xxxxx，你帮我..."
# 代码文件
DATABASE_URL = "postgres://user:password@host/db"
# 工具输出
$ env
ANTHROPIC_API_KEY=sk-ant-...
GITHUB_TOKEN=ghp_...
# 错误信息
ConnectionError: failed to authenticate user 'admin@company.com'
这些会进入 prompt → 进入 cache → 进入日志。不主动检测就会持续累积。
2.2 工具层的 secret 屏蔽
最佳实践：在工具结果进入上下文前做屏蔽。
SECRET_PATTERNS = [
r"sk-ant-[a-zA-Z0-9-]+", # Anthropic API key
r"ghp_[a-zA-Z0-9]+", # GitHub PAT
r"ghs_[a-zA-Z0-9]+", # GitHub server token
r"AKIA[0-9A-Z]{16}", # AWS access key
r"-----BEGIN .* PRIVATE KEY-----[\s\S]+?-----END .* PRIVATE KEY-----",
# ...
]
def redact_secrets(text):
for pattern in SECRET_PATTERNS:
text = re.sub(pattern, "[REDACTED]", text)
return text
def run_bash_with_redaction(cmd):
output = subprocess.run(cmd, ...).stdout
return redact_secrets(output)
注意：
- 这是有损的（误屏蔽合法内容）
- 不是绝对的（漏网模式）
- 但比"全裸传"好得多
2.3 用户输入的处理
用户主动粘贴 secret 怎么办？两种策略：
| 策略 | 行动 |
|---|---|
| 阻断 | 检测到 secret 模式 → 提示用户、不发给模型 |
| 屏蔽后传 | 替换成 [REDACTED] 后传给模型 |
| 警告但传 | 提示用户，仍然发送 |
我倾向屏蔽后传 + 警告：
检测到你的消息含 API key。我已替换为 [REDACTED] 再处理。
建议立即轮换该密钥。如果是必须传给我的内容，请确认敏感后我再处理。
阻断太严苛（用户可能确实需要 agent 帮忙处理含 key 的代码）。完全不管又危险。
3. Memory 的隐私生命周期
3.1 Memory 写入时的过滤
写入 Memory 前过一遍 secret 屏蔽：
def write_memory(content):
redacted = redact_secrets(content)
if redacted != content:
log.warn("Secrets detected in memory content, redacted")
save(redacted)
但要警惕间接信息：
- "用户 alice@example.com 喜欢简洁注释" ← email 是 PII
- "项目部署到 vpc-12345" ← 内部基础设施信息
- "用户的电话是 ..." ← 严格 PII
不只屏蔽 token-like secret，还要识别 PII。
3.2 Memory 的保留期
GDPR 要求"为目的所需的最短时间保留"。Memory 不应永久保留。
| Memory 类型 | 建议保留期 |
|---|---|
| user（偏好、角色） | 用户主动用 agent 期间 + 30 天 |
| feedback（行为纠正） | 1 年（行为模式相对稳定） |
| project（任务状态） | 项目活跃 + 90 天 |
| reference（外部链接） | 链接仍有效就保留 |
实现：每条 memory 加 created_at 和 last_accessed_at，定期清理过期的。
---
name: user_role
type: user
created_at: 2026-05-07
last_accessed_at: 2026-05-07
---
3.3 用户的"被遗忘权"
GDPR 第 17 条赋予用户删除个人数据的权利。Memory 系统必须支持：
def delete_user_data(user_id):
# 1. 删 memory 文件
shutil.rmtree(f"~/.claude/projects/{user_id}/memory")
# 2. 删日志
delete_logs_for_user(user_id)
# 3. 删后台任务
cancel_scheduled_tasks_for_user(user_id)
# 4. 通知 cache 失效（如果是服务端 cache）
invalidate_cache_keys_with_user(user_id)
# 5. 写审计记录（删除事件本身要记录，但不含被删内容）
audit_log("user_data_deleted", user_id)
这种 API 必须第一天就有。等到法律要求才补，可能来不及。
4. 日志的隐私设计
13 篇讲过日志结构。隐私视角下日志最需要分级：
4.1 日志分级
Level 1: 指标日志（事件类型、时间、token 数）
- 包含: timestamp、turn_id、event_type、cost
- 不含: 任何内容
- 保留: 永久（用于趋势分析）
Level 2: 摘要日志（事件 + 摘要）
- 包含: Level 1 + 工具名 + 用户消息长度（不是内容）
- 保留: 90 天
Level 3: 完整日志（事件 + 完整内容）
- 包含: 完整 prompt、工具结果
- 保留: 7-30 天
- 访问: 限定 debug 用途
不同级别存不同位置、不同保留期、不同访问控制。
4.2 日志中的 secret
工具结果可能含 secret，日志会保留它们。所以：
- 日志写入前再过一次 secret 屏蔽（双重保险）
- 日志加密存储
- 访问日志要审计（谁查了什么）
4.3 thinking 块的特殊处理
extended thinking（16 篇）含模型的"内心独白"，可能：
- 提到用户姓名、邮箱
- 复述用户敏感信息
- 写出"用户可能在隐瞒..."这种判断
如果展示给用户都已经敏感，写进日志更敏感。建议：
- thinking 块默认不进 Level 3 日志
- 真要 debug 时单独申请
5. Cache 与隐私
5.1 Anthropic 侧的 cache
Anthropic prompt cache 在 Anthropic 服务器。隐私视角：
- 数据传给 Anthropic 处理（受 Anthropic 隐私政策约束）
- TTL 5 分钟自动过期
- 不能被其他用户读到（cache 按账号隔离）
但用户可能不希望某些内容进入 Anthropic cache：
- 极敏感的合同、医疗信息
- 法律明确不许跨境传输的数据
实操：
- 默认信任 Anthropic（已签 DPA）
- 极敏感场景考虑使用本地模型或 Anthropic 的 PrivateLink / VPC 选项
5.2 自建 cache
如果你的 agent 系统有自建的"提示缓存层"（比如缓存子 agent 结果），隐私责任在你：
- 加密存储
- 访问控制
- TTL 设置
- 用户删除时连带清理
6. 审计与可追溯
合规框架（GDPR、SOC2、HIPAA 等）通常要求：
- 数据从哪来（来源审计）
- 数据被怎么用（使用审计）
- 数据被传给谁（流转审计）
- 数据被怎么删（删除审计）
agent 系统的审计点：
用户输入 → 哪些工具被调用 → 工具访问了什么资源 → 结果存到哪 → 何时清理
每一步要可追溯。13 篇的日志结构是审计的基础设施。
6.1 子 agent 调用的审计
03 篇讲子 agent 隔离。但审计视角下：
- 父 agent 给子 agent 的 brief 含什么数据？
- 子 agent 调用了什么工具？
- 子 agent 的结果回传含什么？
这些都要记录。子 agent 不是隐私"逃生口"。
6.2 hook 触发的审计
05 篇讲 hooks。hook 是用户配置的 shell 命令，可能：
- 把 agent 数据发到外部（curl 上报、通知 webhook）
- 处理后写到本地文件
hook 配置本身要审计（settings.json 的修改记录）。hook 输出也要纳入日志（看它把什么数据带去了哪里）。
7. 跨地域 / 跨主权
某些场景下，数据不能离开特定地理边界：
- 中国数据保护法：某些数据不能出境
- 欧盟 GDPR：跨大西洋传输有特殊要求
- 政府敏感场景：通常要本地化部署
实操：
- API 调用要选对应区域的 endpoint
- 数据存储区域要配置
- 子 agent 不能跨区域 spawn（避免无意中跨境）
- 监控数据流向
这影响上下文工程的"全局架构"决策，而不只是"prompt 写法"。
8. 用户同意的颗粒度
GDPR 要求特定、明示、知情的同意。agent 场景下：
| 用户该被告知 | 默认同意吗 |
|---|---|
| 输入会发给 Anthropic | 必须告知 |
| 输入会进 Memory | 应告知 |
| 输入会进日志 | 应告知 |
| 输入会触发自动化（hook） | 应告知 |
| 数据保留多久 | 应告知 |
| 谁能访问 | 应告知 |
实操中通过：
- 首次启动的隐私说明
- settings 里可调的隐私选项
- 显示"本会话的数据流向"
8.1 撤回同意
用户可能后来撤回某项同意（不再让进 Memory、不再保留日志）。系统要：
- 立即停止该项数据收集
- 清理已收集的（如果用户要求）
- 不能"撤回前数据继续用"（除非有合法保留理由）
9. 特殊场景：医疗、法律、财务
某些行业有额外要求：
- HIPAA（医疗）：BAA 协议、严格审计
- 金融 SOX：操作审计、数据完整性
- 法律保密特权：律师-客户通讯不能进入第三方系统
agent 部署到这些场景：
- 不要用通用 cache（Anthropic 默认 cache 也要评估合规性）
- 强化日志加密
- 操作要可解释、可追溯
- 子 agent 只在合规边界内 spawn
这些场景下，很多通用 agent 优化要为合规让路：
- prompt cache 可能要禁用
- 跨会话 Memory 可能要禁用
- 多模态可能要单独评估
10. 给 Agent 设计者的可迁移规则
- 第一天就建数据敏感度地图：知道每处存什么
- secret 屏蔽在工具层：进上下文前过滤
- PII 不只是 secret：邮箱、电话、内部 ID 都要识别
- Memory 加 created_at / last_accessed_at：支持过期清理
- 支持用户删除权：API 要从第一天就有
- 日志分级：Level 1/2/3 区分保留期和访问权限
- thinking 块特殊保护：默认不进完整日志
- 审计每一步：来源、使用、流转、删除
- hook 也要审计：用户配置的 hook 不是审计盲区
- 跨地域配置要清晰：API endpoint、存储位置、子 agent 边界
11. 一句话总结
上下文工程在隐私场景下不再只是"信噪比最大化"，还要加上"接触面最小化"。每一份数据问三个问题：该存吗？存多久？谁能看？ 把答案做进系统而不是写进文档，agent 才能在合规框架下长期运行。
系列总结（修订版）
至此整个系列共 21 份文档：
| # | 文档 |
|---|---|
| 主 | 智能体上下文工程实现.md（总览 + 导航） |
| 01 | Prompt Cache 与成本 |
| 02 | 注入与信任边界 |
| 03 | 子智能体隔离 |
| 04 | Plan Mode 与 Todo 状态机 |
| 05 | Hooks 与外部信号 |
| 06 | 知识截止与时间感知 |
| 07 | 压缩与拼接算法 |
| 08 | 工具描述作为上下文 |
| 09 | CLAUDE.md 与项目配置 |
| 10 | 错误恢复与上下文修复 |
| 11 | Streaming 与中断 |
| 12 | 多模态上下文 |
| 13 | 可观测性与调试 |
| 14 | 会话接力与长任务 |
| 15 | 多 Agent 协作 |
| 16 | Extended Thinking |
| 17 | 超大 Context 边际成本 |
| 18 | Agent 蒸馏与上下文蒸馏 |
| 19 | 多语言适配 |
| 20 | 隐私、合规与记忆生命周期（本篇） |
整个系列以一个核心主张贯穿：
上下文工程不是让模型看到更多，是让模型在每一刻看到正好的那部分。
20 个章节从 cache 字节匹配到 GDPR 合规，每一篇都是这个原则在某一个维度的展开。
真正的写在最后
这次"我以为写完了"已经经历了三轮：
- 第一轮：主文档
- 第二轮：6 篇细化（→ 7 篇含算法）
- 第三轮：8 篇深入（→ 15 篇）
- 第四轮：5 篇收尾（→ 20 篇）
每次都觉得"够了"，每次又能挖出新的角落。这本身就是上下文工程的一个隐喻：任何看似完整的设计，都还有更精细的层次没考虑。
但工程不是无限完美主义。这 20 篇覆盖的是生产 agent 必须正面回答的问题。还有更深的问题（agent 自我认知、长程目标对齐、价值观注入），但那些已经接近 alignment 研究边界，不在"工程"范畴。
所以在工程层面，这次真的写完了。如果你能从这 20 篇里挑 3 篇放在工作台上反复看 —— 我会推荐：
- 01 Prompt Cache：所有奇怪设计的根因
- 07 压缩与拼接算法：让概念能落地成代码
- 10 错误恢复：决定 agent 在生产能不能活下来
愿你的 agent 在每一刻都看到正好的那部分。
