Agent Dry-Run & Simulation Mode/ 智能体干运行与模拟模式

干运行（Dry-Run）模式是Agent的「演习模式」——让智能体在隔离的沙箱环境中完整执行推理→规划→工具选择的全流程，但**不真正执行任何有副作用的操作**（不写数据库、不发API请求、不修改文件），而是将每一步「如果执行会做什么」完整输出供人工审核。就像Git的 --dry-run 或 Terraform 的 plan 命令：先预览变更，确认安全后再 apply。这是Agent从「开发调试」走向「生产可信」的关键安全机制。

干运行模式的实现包含三个递进层级，从「纯文本预览」到「完整模拟执行」逐步增强：

**① Level 1：计划输出模式（Plan-Only Mode）**

最基础的实现——在System Prompt中增加指令：「请只输出你的执行计划，不要实际调用任何工具」。Agent正常走完推理链（思考→拆解任务→选工具→规划参数），但将工具调用替换为文字描述。例如原本要调用 create_issue(title="修复登录Bug")，实际输出变为「我计划调用 create_issue 工具，参数为 title='修复登录Bug'」。优点是零成本实现，缺点是纯文本无法验证参数类型、工具名是否正确，Agent可能「说一套做一套」。

**② Level 2：Mock拦截模式（Tool-Mock Mode）**

将Agent运行在真实执行环境中，但在工具调用层（Tool Executor）前插入Mock拦截器。当Agent发出工具调用时，Mock层拦截请求、验证参数格式、返回一个符合预期的「假成功」响应，Agent继续正常推理——整个过程Agent「以为自己真的执行了」，实际所有副作用被隔离。例如：Agent调用 GitHub API 创建 Issue → Mock拦截 → 验证参数合法性 → 返回 mock_response = {"id": 99999, "url": "https://github.com/.../issues/99999"} → Agent继续处理。需要预定义每个工具的Mock规则，包括：合法参数范围、返回值格式、错误场景模拟。

**③ Level 3：影子执行模式（Shadow Execution Mode）**

最高级的实现——Agent 同时运行在两个通道：「主通道」正常推理但不执行、「影子通道」在完全隔离的 Staging 环境（独立数据库/测试账户/沙箱仓库）中真实执行。主通道输出审核通过的步骤，影子通道已经验证了该步骤在真实环境中的可行性。例如：Agent要删除 S3 bucket 中的文件，主通道输出计划，影子通道在 test-bucket 中真实执行删除操作并验证权限、参数、API响应全部正确。这实际上是一种「预演+验证」的双重保障机制。

三层模式从「纯文本」到「真实验证」，实际项目中通常Level 2用于日常开发调试，Level 3用于CI/CD流水线中的回归验证。

以下4项可操作测试覆盖从简单到完整的干运行验证体系：

• 测试一：Plan-Only模式一致性验证

• 操作：准备20个典型任务（创建Issue、查询数据、修改配置、发送通知等），让Agent分别在「干运行模式」和「真实执行模式」下各跑一遍。对比两轮的工具调用序列：工具名是否一致？参数是否一致？调用顺序是否一致？干运行「说了要做」但实际执行时「跳过的步骤」就是漏报，「说了不做但实际做了」就是误报。

• 工具：pytest + LangChain/LangGraph（https://github.com/langchain-ai/langgraph）构建测试Agent；用 diff 工具对比两轮的工具调用JSON序列

• 指标：工具调用序列一致率 ≥ 95%、漏报率 = 0%（计划中说了要做但实际没做的步骤）、误报率 = 0%（计划中没说但实际执行了的步骤）

• 测试二：Mock拦截器的边界覆盖测试

• 操作：为每个工具编写5类Mock测试用例：①正常参数→返回成功、②缺失必填参数→返回错误、③参数类型错误（传字符串但需要数字）→返回错误、④参数越界（超长文本/超大数值）→返回错误、⑤并发冲突（同一资源被锁定）→返回冲突错误。确保Mock层能正确模拟所有场景。

• 工具：pytest + unittest.mock（https://docs.python.org/3/library/unittest.mock.html）或 MSW（Mock Service Worker，https://mswjs.io）用于HTTP API Mock；WireMock（https://wiremock.org）用于独立Mock服务器；LangSmith（https://smith.langchain.com）记录Agent执行的完整Trace

• 指标：Mock覆盖率 ≥ 90%（覆盖全部工具的所有错误分支）、Mock响应延迟 ≤ 10ms（不影响Agent推理节奏）、误拦截率 = 0%（不应拦截的请求被错误拦截）

• 测试三：Shadow Mode回归验证管线

• 操作：在CI/CD流水线中集成Shadow Mode——每次Agent的Prompt、工具定义、模型版本变更后，自动运行50个预定义的回归任务。每个任务先跑「主通道」（输出计划不执行），再跑「影子通道」（在Staging环境真实验证）。对比两个通道的结果：主通道计划中的所有步骤是否都能在影子通道中成功执行？影子通道暴露了哪些权限/参数/流程问题？

• 工具：GitHub Actions / GitLab CI Pipeline + Docker Compose（Staging环境）；OpenAI Evals（https://github.com/openai/evals）作为评估框架；Allure（https://github.com/allure-framework）生成测试报告

• 指标：通道一致率 ≥ 90%（主通道计划能被影子通道成功执行的比例）、回归率 ≤ 5%（新版本引入的失败案例）、回归检测时间 ≤ 15分钟（从变更到出结果）

• 测试四：干运行模式的用户体验评估

• 操作：让3-5名开发者使用带干运行功能的Agent完成真实任务（如批量修改代码、操作数据库迁移），收集反馈：预览信息是否足够清晰？从预览到确认执行的流程是否顺畅？是否出现过「预览看起来没问题但执行时出错」的情况？记录从「看到预览」到「点击确认执行」的平均决策时间。

• 工具：Grafana Faro（https://github.com/grafana/faro）前端埋点追踪用户行为；自建反馈表单/问卷

• 指标：用户确认率 ≥ 70%（看到预览后选择继续执行的比例）、误确认率 ≤ 5%（确认执行后仍出错）、预览理解时间 ≤ 30秒（用户从看到预览到做出决定）、满意度评分 ≥ 4.0/5.0

1. 「预览即承诺」的幻觉陷阱——Agent在干运行模式中输出的计划看起来完美，但实际执行时由于LLM的非确定性（temperature > 0）、上下文细微变化（并发会话干扰）、或外部系统状态变更（数据被其他进程修改），可能导致实际执行结果与预览完全不同。解决：① 干运行时使用 temperature=0 提升确定性；② 在确认到执行之间加「关键状态快照」检查（执行前再验证一次前置条件）；③ 对每一次差异做根因分析并更新Mock规则。

1. Mock数据的「过度拟合」问题——Mock层返回的总是「理想化」的假数据，Agent在Mock环境中「永远成功」，但切换到真实环境后遇到各种边界情况（网络超时、API限流、数据冲突）就会崩溃。解决：Mock规则中必须包含错误场景（至少30%的Mock用例是失败场景），并引入「混沌工程」思维——在影子通道中随机注入故障（延迟、错误、部分失败），训练Agent的容错能力。

1. 影子环境的「环境偏差」陷阱——Staging环境和生产环境之间必然存在差异（数据量不同、权限不同、网络拓扑不同），影子通道中验过的操作在生产中仍可能失败。解决：① 定期从生产环境脱敏同步数据到Staging；② 记录影子通道和生产通道的差异率趋势，监控「环境偏差」是否在扩大；③ 对高风险操作（删除、金钱交易、权限变更）永远保留Human-in-the-Loop最终确认，不完全依赖自动化验证。

• Anthropic — Tool Use Best Practices（含安全执行建议）: https://docs.anthropic.com/en/docs/build-with-claude/tool-use

• LangGraph — Human-in-the-Loop & Interrupt Patterns: https://langchain-ai.github.io/langgraph/how-tos/human_in_the_loop/

• OpenAI — Evals 评估框架（用于干运行回归测试）: https://github.com/openai/evals

• MSW (Mock Service Worker) — API Mock 标准方案: https://mswjs.io

• Terraform Plan & Apply 模式（干运行的经典工程实践）: https://developer.hashicorp.com/terraform/tutorials/cli/plan