# 订单运营执行 Agent > 周期建议：10–14 天。所有订单和工具均为本地 Mock；系统不得连接真实电商、支付、物流或消息平台。 ## 项目背景 一个虚构电商的运营人员每天处理“查订单、修改地址、拦截发货、申请退款、发放小额补偿”等请求。只做对话机器人无法完成工作；让 Agent 直接调用真实动作又很危险：它可能在订单已发货后改地址，重复退款，或执行到一半失败而没有补偿和记录。 团队需要一个执行型 Agent 样板：先读上下文并形成可审查计划，再按工具契约和风险规则决定“直接执行”还是“等待人工审批”，对重复请求保证幂等，对部分失败给出补偿结果，并留下完整审计。 ## 项目目标 交付一个本地订单运营控制台，完成“输入运营目标 → 获取订单上下文 → 生成结构化计划 → 风险判断 → Mock 工具执行/审批 → 幂等重放 → 失败补偿 → 审计追溯”的闭环。 核心评价不是 Agent 会调用多少工具，而是副作用是否被约束、解释和验证。 ## 用户故事 - 作为运营人员，我希望先看到 Agent 的动作计划和依据，从而在执行前发现误解。 - 作为审批人，我希望高风险动作只有确认后才执行，从而保留人为责任边界。 - 作为系统负责人，我希望重复请求不会产生重复退款或补偿，从而控制副作用。 - 作为审计人员，我希望查看计划、工具输入、审批、结果和补偿，从而复盘一次执行。 ## 功能要求 ### 必须完成 1. **合成订单域** - 提供订单、支付、履约、地址和风险标签的本地种子数据。 - 订单状态与允许动作有明确约束，例如已发货订单不能直接修改地址。 2. **有限工具注册表** - 至少实现：`get_order`、`grant_coupon`，以及 `change_address`、`intercept_shipment`、`request_refund` 中的两项。 - 每个工具定义名称、用途、结构化输入/输出、前置条件、风险等级、幂等要求和可能错误。 - Agent 只能选择注册工具；用户文本不得创造任意工具名、URL 或命令。 3. **先计划、后执行** - 把运营目标转成结构化计划，至少包含步骤、工具、参数摘要、依据、预期效果、风险与依赖。 - 计划生成后必须重新读取并校验当前订单状态，防止基于过期状态执行。 - 低置信或缺少关键参数时返回澄清，不得猜测地址、金额或订单号。 4. **风险与审批边界** - 集中维护风险矩阵；低风险 Mock 动作可直接执行，高风险动作必须创建审批单。 - 审批单包含计划快照、风险原因、关键参数和影响；批准前工具不会产生副作用。 - 拒绝、过期、已处理审批不可再次执行；审批时再次校验业务前置条件。 5. **幂等执行** - 所有副作用工具必须接收幂等键，并将键与动作、目标和请求摘要绑定。 - 相同键和相同请求返回原结果；相同键但请求内容不同必须拒绝冲突。 6. **失败与补偿** - 提供一个可稳定触发的多步骤失败场景。 - 记录已完成步骤、失败步骤、可补偿动作和补偿结果；若无法自动补偿，进入人工处理而非假装回滚成功。 7. **审计与操作台** - 可查看目标、计划版本、上下文快照、每次工具调用、幂等重放、审批决定、错误和补偿。 - 审计事件按时间追加，普通业务接口不能改写历史。 ### 可选增强 - 计划模拟（dry-run）、审批过期、工具级超时/重试策略。 - 规则变化后的计划失效检测。 - 可视化 Tool Calling trace 或事件时间线。 - 真实 LLM Adapter 接口；默认演示仍为确定性规则/Mock Agent。 ## 非功能要求 - **可运行性**：提供多种订单状态和操作脚本，离线可演示直接执行、审批、幂等和补偿。 - **一致性**：业务状态、执行记录和幂等记录必须协同提交，避免“动作成功但无记录”。 - **可靠性**：未知工具、非法状态迁移、并发审批、重复执行和超时都有确定处理。 - **性能**：本地读取订单和生成 Mock 计划各应在 2 秒内完成；工具超时可配置。 - **可解释性**：任何执行/拒绝/审批都能看到规则、上下文与理由，不能只返回“Agent 决定”。 - **安全**：工具参数做服务端校验；用户文本不能绕过审批、访问环境秘密或调用任意网络地址。 - **无障碍**：高风险状态有明确文字与确认摘要，核心按钮可键盘操作且不可仅靠颜色区分。 ## 范围与限制 ### 范围内 - 单团队、本地订单运营演示。 - 合成订单、有限工具、结构化计划、风险审批、幂等、副作用模拟、补偿和审计。 - 规则/Mock Agent 对预设运营目标的确定性解析。 ### 范围外 - 连接真实电商、支付、物流、优惠券、短信或客服系统。 - 真实退款、地址修改、发货拦截、优惠发放或外部通知。 - 通用工作流平台、复杂组织权限、自动批准高风险动作。 - 复制现有订单运营项目源码、客户数据或生产工具契约。 ### 技术与时间限制 - 周期为 10–14 天；先完成两个副作用动作的可靠闭环，再增加工具数量。 - 技术栈可自选，必须提供操作 UI 和可自动测试的计划、审批、执行 API。 - 数据与工具全部本地 Mock；测试不得访问公网，也不得要求真实平台或模型凭证。 - 真实 Provider 只能是可替换 Adapter，不能影响默认测试的确定性。 - 不要求部署；自行部署不得开启真实动作、产生费用或失去本地验收能力。 ## 澄清机制 在“澄清 Issue”中记录背景、歧义、候选方案、推荐、后果和未回复时采用的可逆假设。 例如“金额多少算高风险退款”属于审批边界，必须明确，不能由 Agent 临时决定。只影响页面排序的问题可记录假设继续；涉及真实动作、审批绕过、金额/地址、外部消息、账号或费用的问题必须等待组织者确认。遇到规则无法覆盖的 D/or 状态，应进入人工处理并保留证据，而不是强行映射为成功或失败。 ## 交付物与证据 - 可运行源码、依赖锁文件、安全配置示例、数据库迁移和合成订单夹具。 - `README.md`：架构、工具契约、风险矩阵、启动、四条演示路径、测试和限制。 - `docs/PRD.md`：角色、动作状态、审批与风险边界、范围、验收映射和澄清决策。 - `docs/PLAN.md`：计划器、策略、工具、幂等、审批、补偿和审计的数据流与一致性设计。 - 自动化测试：至少覆盖前置条件、未知工具、澄清、审批前无副作用、幂等冲突、并发审批、部分失败和补偿。 - `docs/TEST_EVIDENCE.md`：命令、结果、验收映射及直接执行/审批/重放/补偿证据。 - `docs/AI_COLLABORATION.md`：AI 参与、本人核验与未采纳建议；不得粘贴私人会话全文。 - `docs/RETROSPECTIVE.md`、阶段 Issue、PR 和清晰提交历史。 ## 公开可测试验收标准 | ID | Given / 前置条件 | When / 操作 | Then / 可观察结果 | 验证方式 | |---|---|---|---|---| | AC-01 | 一个存在的未发货合成订单 | 输入“查询订单并给 10 元关怀券” | 计划先调用查询再调用补偿工具，展示依据和风险；执行后状态可核对 | 集成测试 | | AC-02 | 目标缺少订单号或退款金额 | 生成计划 | 系统返回结构化澄清，不猜测参数、不调用副作用工具 | 自动化测试 | | AC-03 | 一个高风险地址修改/退款计划 | 点击执行但尚未批准 | 只创建一张审批单，订单、退款和地址均未改变 | 自动化测试 | | AC-04 | 高风险计划已批准，但订单状态在审批期间改变 | 尝试执行 | 系统重新校验并拒绝过期计划，记录规则与新状态 | 集成测试 | | AC-05 | 一个低风险副作用请求已成功，幂等键为 K | 使用 K 重放完全相同请求 | 返回原执行结果，不产生第二次补偿或第二条业务变更 | 自动化测试 | | AC-06 | 幂等键 K 已绑定请求 A | 使用 K 提交参数不同的请求 B | 返回幂等冲突，A 与 B 均不会被二次执行 | 自动化测试 | | AC-07 | 同一审批单待处理 | 模拟两次并发批准 | 至多一次工具执行成功，另一请求得到已处理结果 | 并发测试 | | AC-08 | 使用文档约定的第二步故障场景 | 执行多步骤计划 | trace 显示已完成/失败步骤与补偿结果；不能补偿时进入人工处理 | 故障集成测试 | | AC-09 | 全新环境且无平台/模型凭证 | 按 README 启动并运行测试 | 计划、直接执行、审批、幂等和补偿均可本地复现，无真实副作用 | 人工复现 + 命令证据 | ## 技术讲解与追问准备 请准备说明：计划为什么不是授权；工具契约如何限制模型输出；风险矩阵和审批如何执行；幂等键绑定哪些内容；业务前置条件为什么在批准后再校验；部分失败和补偿如何留痕；AI 生成实现如何被并发与故障测试验证。 验收可能临时增加一个工具或修改风险规则。你需要先澄清副作用、幂等、审批和补偿影响，再设计最小变更并提供完整回归证据。 ## 安全与合规 - 只能操作合成订单和本地 Mock 工具，严禁连接真实支付、物流、电商、优惠券或消息系统。 - 不得自动执行真实退款、改址、拦截、补偿或通知；高风险 Mock 动作也必须遵循人工审批边界。 - 用户输入和 Agent 计划均是不可信数据，不能绕过服务端校验、审批或工具白名单。 - 不得提交、共享或中转平台、支付、Codex 或模型账号、会话、Token、API Key、Cookie、私钥。 - 本活动用于项目实践和能力反馈，不承诺就业、录用、薪资或面试结果。