08｜模型、规则、工具和人，应该怎样分工？

架构首先要回答责任分配。哪些判断必须稳定一致，哪些输入需要语义理解，哪些动作由原系统提供，哪些决定需要人来作出。分工明确之后，再选择组件和连接方式，系统才有可检查的边界。

一套可交付方案，应当让每一步的输入、依据、动作、状态与失败去向都能被解释。

模型擅长处理开放表达，例如把“带师傅、两天”整理成待确认的服务需求，结合材料说明候选方案，或归纳客户的修改意见。模型输出可以是候选判断，需要通过相应的业务与工程约束进入后续流程。

确定性规则负责那些应当按明确条件得到一致结果的工作。日租费用、运输次数、预算上限、必填字段和状态转换条件，都适合由可以检查的程序处理。规则变化需要记录版本，不能只藏在一段随时可能改写的提示词中。

检索和查询负责取得依据。文档检索可以找到相关条款与经验，结构化查询可以取得当前设备或库存记录。两者都需要遵守对象、时间和权限边界，再把结果交给后续处理。

工作流负责稳定步骤、等待、分支与状态，例如生成草稿后等待核对，批准后创建任务，执行失败后进入异常处理。Agent 可以在许可范围内选择工具和调整查询路径，却不应绕过这些正式状态约束。

人工负责需要专业判断、正式授权或风险接受的决定。人工介入必须有明确触发条件、接手角色和恢复方式。一个“请人工处理”的提示，如果没有足够上下文和具体接手人，往往只是把问题留在原地。

工具调用不是给模型一张数据库的万能通行证。更容易控制的方式，是提供与业务任务相符的能力，例如查询候选资源、按指定价目计算费用、生成报价草稿、提交审批请求。

每个工具都应有接口契约：输入字段、输出含义、身份要求、参数限制、错误返回以及是否产生副作用。副作用指工具可能改变业务状态，例如创建订单、占用资源或发送通知。只读查询与写入动作需要不同的控制强度。

幂等可以用一个业务例子理解：同一项确认请求由于网络问题被重复发送，不应因此创建两份相同任务或重复占用资源。实现方式取决于系统，但业务上需要能识别同一请求，并检查当前状态是否仍然允许执行。

工具返回也不能只有一段自然语言“操作成功”。至少应能够判断成功、失败或结果未知，关联到具体对象与版本。写入超时尤其需要核对实际状态，盲目重试可能放大后果。

“人在回路”常用 HITL 表示。有效的人工介入，应当放在信息足够、动作尚可控制的位置。

设备租赁中，调度需要看见当前需求、报价接受状态、候选设备和人员、资源记录时点及待核实项，才能确认安排。若系统先占用资源，再让人点击“确认”，审批就只剩下事后形式。

礼品设计中，客户确认应绑定具体作品和版本。如果一件作品已改成新版，旧版确认不能自动继承。物流中，负责人批准的是某个时点、预算和数量条件下的方案；事实变化可能要求重新计算与审批。

人工节点还需要拒绝、要求补充、修改后重提等路径。只设计“通过”，等于假设所有异常都会在审批前消失。审核意见应回到业务状态，让下一位操作者知道当前等待什么，而不是只保存在聊天里。

以报价为例，首个切片可以选普通两天询价，覆盖需求补齐、有效价目查询、费用计算、候选资源展示和调度复核入口。先限制设备类型与场景，保证整条任务能够被观察。

图中的每个箭头都对应实际传递的信息。开发时应检查上一段输出是否足以支持下一段，而不仅是每个组件能否单独运行。只有调度能读取当前版本，报价草稿才真正进入后续工作。

同时安排至少一条失败路径，例如档期过期、客户改期或工具不可用。正常链路说明系统能够做什么，失败链路说明它何时应停下，以及停下后人能否接手。

有些未知需要完整切片，例如消息入口、身份、数据和业务回流能否共同成立；有些未知可以先用限时实验检查，例如某接口是否支持查询、图片解析是否能够取得必要字段。这类专项探索常称为 Technical Spike。

专项实验可以降低局部不确定性，但不能自动证明整体可交付。如果图片解析通过了，商品映射、重复识别、库存更新和人工复核仍需要在完整任务中验证。

验证计划应写清待证假设、输入条件、成功标准、预算、停止条件和决定用途。比如“若当前资源无法通过现有接口取得，则本轮改为人工提供经过核对的快照，并明确结果时效”。这样失败结果也能推进方案决策。

架构决策记录常用 ADR 表示，可以简短记录比较过哪些选项、受到什么约束、证据支持什么选择，以及选择带来的责任。后续条件变化时，团队能够重新判断，而不必猜当初为什么这样设计。

同一套能力，可以内嵌在现有业务系统，也可以通过消息入口提供，或先用独立页面开展有限验证。选择不仅取决于界面体验，还取决于身份能否传递、数据能否获得、结果能否回流以及维护成本。

如果客户暂时只能每日交换文件，系统可以在这个条件下验证有限任务，但必须说明数据是批次更新，不能承诺实时库存。若模型运行环境受限，则要比较本地资源、可用能力和任务范围，必要时调整自动化程度。

过渡方案也应有清楚边界。用文件替代接口时，需要版本与对账；独立页面先行时，需要明确如何把结果交回原岗位；人工提供数据时，需要记录确认人和时点。过渡不意味着可以省略业务责任。

设计评审时，可以选一笔代表任务，逐步填写下面的内容。若某一栏长期无法回答，通常说明方案还有缺口。

架构是否清晰，最终体现在业务变化能否被正确处理。客户改了日期、数据出现冲突、授权条件改变时，系统应该知道哪些结论需要重算、哪些动作不再允许、哪些责任需要重新确认。

从下一篇开始，我们将用设备租赁、礼品设计和物流三个案例，逐步检验这套分工在不同业务条件下怎样成立。

AI随心创提供AI 工作流设计，围绕输入、生成、校验、人工审核、交付和复盘组织方案，也可结合图片、视频、配音及小红书内容生产讨论多环节协作。可以用本篇分工表说明当前流程最需要改善的位置。