周期建议：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 和清晰提交历史。

公开可测试验收标准

技术讲解与追问准备

请准备说明：计划为什么不是授权；工具契约如何限制模型输出；风险矩阵和审批如何执行；幂等键绑定哪些内容；业务前置条件为什么在批准后再校验；部分失败和补偿如何留痕；AI 生成实现如何被并发与故障测试验证。

验收可能临时增加一个工具或修改风险规则。你需要先澄清副作用、幂等、审批和补偿影响，再设计最小变更并提供完整回归证据。

安全与合规

• 只能操作合成订单和本地 Mock 工具，严禁连接真实支付、物流、电商、优惠券或消息系统。
• 不得自动执行真实退款、改址、拦截、补偿或通知；高风险 Mock 动作也必须遵循人工审批边界。
• 用户输入和 Agent 计划均是不可信数据，不能绕过服务端校验、审批或工具白名单。
• 不得提交、共享或中转平台、支付、Codex 或模型账号、会话、Token、API Key、Cookie、私钥。
• 本活动用于项目实践和能力反馈，不承诺就业、录用、薪资或面试结果。