AI Agent落地：任务合同五步法

读完可把模糊需求写成任务合同，明确输入输出、工具权限、失败预算和回滚线，今天就能启动上线评审。

作者：进学斋 · 观山书院

全文约3923字 · 阅读约需14分钟

---

最近一个做客服 Agent 的团队给我看 demo，输入工单文本，输出处理建议，现场跑得很顺。可一放到真实工单池，问题立刻出来：它会不会改用户资料？会不会替客户承诺退款？出错以后能不能追回？这类问题，单靠提示词很难回答。真正可落地的 Agent，需要先拿到一份任务合同。

你可以把这份合同理解成 Agent 的岗位说明书：它负责什么，能看到什么，能调用什么工具，失败了怎么退回去，谁批准后才能动关键系统。读完这篇，你会拿到一套五步上线法、一份合同字段示例、一张架构选型对照表，今天就能启动评审。

—— 先让边界说话，再让模型表演。

一、先给 Agent 定边界

把需求拆成四类，别急着接工具

很多需求一开始都很模糊：做一个智能客服助手，做一个报告整理 Agent，做一个工单分诊机器人。听起来都能跑，但边界没有拆开。落地第一步不是选模型，而是把目标、输入、输出、禁止动作写清楚。

目标要可验证。比如，把工单分到正确队列，给出下一步建议。输入要有限定。比如，只读取用户描述、历史工单摘要和产品规则，不读取手机号、地址、支付信息。输出要固定格式。比如，输出 JSON，包含分类、优先级、置信度、建议动作。

禁止动作比自动动作更重要

一个 Agent 上线前，最危险的不是它做不了什么，而是它擅自做了什么。退款、发送优惠券、修改订单、写邮件、创建外部账号、删除文件，这些都要先列进禁止动作。

你可以把动作分成三档：可自动、需审批、必须禁用。低风险动作可以自动，比如生成摘要、归类标签、给出话术建议。中高风险动作需要审批，比如发送邮件、提交工单、创建任务。高风险动作直接禁用，比如退款、改价、导出敏感数据、删除记录。

用任务合同替代长篇 PRD，不是为了减少沟通，而是让产品、技术、业务能在同一页纸上确认：这个 Agent 到底能不能上线。

—— 合同不是文档，是可执行边界。

配图·春野柔光

二、任务合同核心字段

一份最小可用的任务合同

合同字段不必长，但要可执行。下面是一段可直接放进项目仓库的 YAML 示例，适合工单分诊、报告整理这类场景。

contract:  id: ticket-triage-v1  objective: 将新进工单分类到正确队列，并给出下一步处理建议  context:    ticket_pool_snapshot: current_day    knowledge_base_version: rules_v1    business_rules_version: cs_v3  input:    allowed_fields:      - ticket_text      - user_type      - product_name    forbidden_fields:      - phone      - address      - payment_id  output:    format: json    required:      - category      - priority      - confidence      - next_action  tools:    read_only:      - knowledge_base_search      - ticket_history_query    write_allowed: []    approval_required:      - create_followup_ticket  dependencies:    mcp:      allowed_servers:        - ticket_service      read_only: true    function_calling:      whitelist:        - knowledge_base_search        - ticket_history_query  forbidden:    - refund    - price_change    - export_user_data    - delete_ticket  data_boundary:    retention: 24h    redaction:      - email      - phone  failure_budget:    auto_retry: 1    max_error_rate: threshold_by_business  rollback_line:    mode: human_queue    fallback: rule_based_router

每个字段都要能验收

目标字段不能只写“提升效率”。要写成日志可统计、结果可抽查的条件。比如，分类字段必须命中枚举值；置信度低于阈值的任务必须进入人工队列。

工具权限不能只写“允许调用知识库”。要写明哪个接口、什么参数、只读还是写入、是否记录 trace id。MCP、Function Calling、RAG 知识库这些依赖，都要变成可验证条件：能不能调用，调用了什么，返回什么，失败后怎么办。

上下文字段同样关键。当前工单池快照、知识库版本、业务规则版本，最好都能写进合同。否则，同一类问题昨天能答对，今天答错，排查时很难定位是模型问题、数据问题，还是规则漂移。

数据边界决定安全线。哪些字段可以进入模型上下文，哪些必须脱敏，哪些完全不能读，要在合同里写死。失败预算决定运维线。允许重试几次，超过阈值触发什么降级，不能出错后才临时决定。

回滚线决定业务信心。出错时是切换人工队列，还是降级到规则引擎，还是直接暂停写入，都要提前指定负责人。

—— 先试只读，再放写入。

配图·庭园小径

三、五步落地实战

第一步：评审合同

拉上产品、技术、业务三方，开一次短会，只过合同字段。不要讨论模型能力，先确认输出标准、权限边界和禁止动作。

评审时要问三个问题：输出错了谁来判定？工具调用越界谁来拦截？业务方能不能接受最坏结果？如果三方没有一个明确答案，先别上线。

第二步：只读试点

只读试点是最稳的启动方式。Agent 只能读取数据、生成建议，不能写回任何系统。比如，只给工单打标签、给客服推荐话术、给报告生成提纲。

试点期关注三类证据：日志里能看到完整链路，指标里能看到错误率，抽查里能看到真实业务判断。据公开资料和行业观察，很多团队最初不敢上 Agent，不是因为模型不够聪明，而是因为缺少可追溯的链路。

第三步：灰度审批

低风险动作可以自动执行。中高风险动作走审批队列。比如，生成退款解释可以自动，提交退款不能自动；创建跟进工单可以自动，修改用户联系方式必须审批。

灰度策略可以按业务域、用户类型、时间窗口或工单标签逐步放开。每一次放开，都要能单独回滚。

第四步：回滚演练

上线前不要只做成功路径测试。要故意制造失败：模型返回非法 JSON、工具超时、知识库不可用、分类置信度过低。然后看系统是否真的能切到人工队列或规则降级。

回滚演练要记录时间。如果从发现错误到业务方接管需要十几分钟，合同就要收紧，先回到只读模式。

第五步：复盘台账

复盘不是写事故报告，而是更新合同。每次失败要归因：是提示词问题，还是工具权限问题，还是数据边界问题，或是业务规则不清晰。

台账至少记录：时间、任务 id、错误类型、影响范围、是否自动恢复、后续动作。下一次评审，合同字段必须跟着变。

—— 不同架构，不同风险，不同成本。

四、常见坑与选型

团队常见的坑有四个：没有幂等，重试后可能重复创建工单；没有审批，模型一激动就可能执行写操作；没有可观测，出错后无法还原链路；没有降级，异常一发生就整条业务停摆。

下面是四种常见形态的对比。选型不要追新概念，要看当前任务的风险等级。

优先选择低风险场景

第一批上线不要选退款、支付、批量群发、账号注销。可以选只读客服、工单分诊、报告整理、会议摘要、知识库问答、规则初筛。这些场景即使出错，影响通常有限，也更容易收集验收数据。

一个实用判断：如果最坏结果只是“建议不准”，可以试点；如果最坏结果是“钱发错、文件被删、客户被误发通知”，先不要自动执行。

—— 能写下来，才叫准备就绪。

五、上线前检查清单

☐ 合同里已写清输出验收和禁止动作。

☐ 工具权限已分成只读、可写、需审批三档。

☐ 数据边界已标注允许字段、禁用字段和脱敏字段。

☐ 上下文版本已记录，便于复现和追溯。

☐ 失败预算已定义重试次数、错误阈值和触发降级的条件。

☐ 回滚路径已演练过：人工队列、规则降级或暂停写入。

☐ 日志能定位一次完整任务链路：输入、工具调用、输出、耗时、错误码。

☐ 抽查机制已建立：每天或每周抽取样本，由业务确认结果是否可用。

☐ 灰度名单已确定：哪些业务域先上，哪些保持只读。

你今天就能做的三件事

第一，把当前 Agent 需求改写成合同字段，控制在半页以内。

第二，列出禁止动作清单，发给业务方确认。

第三，启动只读试点，把日志、指标和抽查表拉通。

三句话讲透：边界写在合同里，上线走灰度里，改进落在台账里。

如果这份任务合同模板能帮你少开几次返工会，可以收藏或转发给产品、测试和业务负责人。