正文

如果你准备让 AI Agent 跑几个小时、几天，或者跨会话继续处理同一个项目，先确认它会保留什么。长任务 Agent 需要环境、文件、缓存、工具连接和执行日志；这些东西一旦跨任务留存，隐私风险就会从“这次 prompt 暴露了什么”变成“这个环境以后还能访问什么”。

TechRadar 在 2026-06-12 报道，OpenAI 计划收购 Ona，重点是让 Agent 拥有安全、持久的环境，以便访问工具、系统和上下文，并在较长时间内继续推进任务。参考：TechRadar 报道。

这类变化对开发者很直接。Agent 现在可能在云端或本地环境里保存项目状态、记住仓库细节、继续执行计划、调用 MCP Server、复用缓存，并在你关闭电脑后继续工作。你需要先把隐私隔离规则写清楚，再把敏感项目交给长任务 Agent。

先确认哪些东西会留在环境里

你现在要把“环境”拆成可检查对象。

如果你不知道这些对象保留多久、谁能访问、怎么删除，就不要把生产数据、客户数据或长期凭据放进 Agent 环境。

ephemeral 和 persistent 要分开用

GitHub 文档说明，Copilot cloud agent 会在 GitHub Actions 支撑的临时开发环境中工作，可以探索代码、修改文件、执行测试和 lint。文档也提到，cloud agent 可以在后台完成任务、携带 Copilot Chat 上下文、使用 Copilot Memory、连接 MCP Server，并受 59 分钟 session 限制。参考：GitHub Copilot cloud agent 文档。

你可以把 Agent 环境分成两类：

临时环境的目标是任务完成后能清掉。持久环境的目标是跨任务继续工作。你不能把两者混成一个默认工作区。

长任务开始前先做数据分级

长任务 Agent 启动前，先给数据分级。不要等它读完仓库后再决定哪些东西敏感。

如果 Agent 必须理解受限数据，先做脱敏样本。让它看结构、字段和边界，不要直接给真实用户记录。

凭据只给短期权限

长任务 Agent 需要调用工具时，不要把人类账号的长期 token 交给它。持久环境一旦保存了 token，风险会跨越单次任务。

你可以按下面方式给权限：

凭据过期时间要短于任务周期。任务跑完后，自动撤销 token，比让 Agent 自己“记得不用”可靠。

记忆和缓存要能审计

Persistent agent 会保存文件，也可能保存记忆和缓存。2026 年 5 月的一项 persistent agent case study 记录了一个持续研究环境：96 个 active days、502 个 memory-related files、17 个 agent directories、57 个 skill files，并显示严格轨迹子集里 82.9% tokens 来自 cache reads。参考：Persistent AI Agents in Academic Research。

这个案例提醒开发者：长任务 Agent 的成本和风险可能从“每次调用”转向“长期环境”。你需要知道记忆里保存了什么。

你可以要求环境支持这些操作：

如果一个工具只说“它会记住你”，但不给查看和删除入口，不适合处理敏感代码库。

• 查看 Agent 记住的项目规则和结论。
• 删除某个仓库、客户或任务的记忆。
• 区分用户记忆、项目记忆和组织记忆。
• 查看缓存是否跨任务复用。
• 禁止把 secret、客户样本、日志片段写入长期记忆。

MCP session 要防重放和串权

长任务 Agent 常常会通过 MCP Server 连接 GitHub、文件系统、数据库、浏览器或企业工具。MCP 官方安全建议列出了 confused deputy、token passthrough、SSRF、session hijacking、本地 MCP Server compromise、scope minimization 等风险。参考：MCP Security Best Practices。

你现在要重点看三类 MCP 状态：

长任务 Agent 会放大这些风险。一次短会话里的错误可能很快结束；持久环境里的错误 session 可能在后续任务继续可用。

让信息流跟着任务走

GAAP 论文提出一种 Agent 执行环境，用信息流控制跟踪私密数据在任务步骤之间、跨多个任务之间的访问和使用。论文强调，系统不能只信任模型或 prompt；它要按用户给出的权限规格，确定哪些私密数据可以披露给模型、工具或外部方。参考：An AI Agent Execution Environment to Safeguard User Data。

开发团队可以先用更简单的版本落地：让每个长任务都带上数据流记录。

这份记录能让 reviewer、管理员和安全同事知道 Agent 被允许读什么、不能碰什么、任务结束后该清什么。

agent_data_boundary:
  task: "整理企业客户导入失败问题"
  allowed_data:
    - "脱敏后的失败样本"
    - "导入模块源码"
    - "测试环境日志"
  blocked_data:
    - "生产数据库 dump"
    - "客户原始手机号和邮箱"
    - "支付凭据"
  allowed_tools:
    - "read_repo"
    - "run_unit_tests"
    - "create_pull_request"
  blocked_tools:
    - "query_production_db"
    - "send_slack_message"
    - "write_cloud_config"
  retention:
    workspace_ttl_hours: 24
    memory_write_allowed: false
    logs_redact_secrets: true

多 Agent 协作要隔离上下文

Confidential computing survey 指出，LLM-driven agents 会规划、调用工具、维护 persistent memory，并通过 MCP、A2A 等协议委托给其它 Agent；这会带来 prompt injection、context exfiltration、credential theft 和 inter-agent message poisoning 等风险。参考：When Agents Handle Secrets。

如果你让多个 Agent 协作，不能让它们共享同一份全量上下文。

上游 Agent 的权限不应该自动传给下游 Agent。每次委托都要重新确认数据范围、工具范围和日志保留。

任务结束后要清环境

长任务完成后，别只看 PR 有没有合并。你还要收尾环境。

如果任务失败，也要执行这套清理。失败任务更容易留下调试日志、半成品文件和扩大权限后的工具连接。

• 撤销临时 token 和 OAuth grant。
• 删除临时工作目录、构建产物和下载文件。
• 清理包含客户数据的日志和测试输出。
• 检查 Agent memory 是否写入了敏感摘要。
• 关闭不再使用的 MCP Server session。
• 保存必要审计记录，不保存明文 secret。

哪些任务不要放进持久环境

有些任务不适合交给 persistent environment。

持久环境适合保存项目规则、任务状态和脱敏上下文。它不适合当作“什么都能放进去的开发电脑”。

团队先改哪几项

如果团队已经在试长任务 Agent，可以先做这些动作。

先做这几项，就能把长任务 Agent 从“能继续干活”变成“能按边界继续干活”。

• 给每个 Agent 环境设置数据等级：公开、内部、受限、机密。
• 给 workspace 设置 TTL：任务完成或超时后清理。
• 禁止把 secret、生产 dump、客户原始数据写入 memory。
• 给工具 token 设置短期、单任务、单 scope。
• 给 MCP Server 设置 per-server 授权和 session 过期。
• 要求每个长任务记录 allowed data、blocked data、allowed tools、retention。
• 每周审计一次 memory、缓存、日志和活跃 session。

结论：持久环境要按数据边界验收

Persistent environment 让 Agent 能处理更长、更复杂的任务。它也让隐私风险跨越单次 prompt、单次 PR 和单次 session。

你现在要把长任务 Agent 当成一个会保存状态的开发环境来管理：它读过什么、记住什么、缓存什么、拿过哪些 token、连接过哪些工具、任务结束后清理了什么。只有这些边界清楚，长任务 Agent 才适合进入真实团队工作流。

参考来源

相关文章