ARTICLE · 1131472
产品经理学 AI Agent(四):AI、软件还是人工?4 种建设模式怎么选
大家好，我是老袁，专注产品 AI 建设与落地实战。
很多 AI 项目一开会，就直接讨论模型、RAG、Agent 和工作流。
需求只是计算固定税率，也想让大模型判断；AI 生成一段高风险结论，未经校验就触发业务操作；所有 AI 输出都交给人工确认，最后发现审核成本和原来差不多。
技术组件都用了，系统却没有获得预期收益。问题往往出现在更早的位置：建设模式没有选对。
前三篇，我们依次讲了 Agent 的能力分层、业务交互契约和内部框架。这一篇往前走一步，回答项目启动时就要确定的问题：一个业务任务应该交给传统软件、AI、人工，还是由三者共同完成？
技术方案可以讨论模型，产品决策要先看任务。
一、两个判断轴：任务确定性与错误风险
选择建设模式，可以从两个相互独立的维度开始。
第一个维度是任务确定性，用来判断主要由程序还是 AI 完成。
高确定性任务通常具备这些特征：输入结构化、规则可以枚举、结果可以计算，相同输入应得到相同输出。例如计算退款金额、判断签收是否超过 7 天、检查账户权限。
低确定性任务需要理解自然语言、图片或复杂文档，也可能面对模糊条件和开放式输出。例如判断用户是在咨询、投诉还是申请退款，或者从合同中识别潜在风险。
第二个维度是错误后果风险，用来决定结果能否直接使用。
判断风险时，至少要看六件事：损失金额、影响人数、操作是否可逆、错误是否容易发现、修复成本，以及最终责任由谁承担。涉及资金、健康、法律、账户权限和客户权益的任务，还需要考虑监管、审批和审计要求。
两个维度组合后，可以得到四个象限：
这张表用于完成任务分类。后续还要结合结果如何使用、谁来确认，以及是否触发业务动作，选择具体的建设模式。
任务确定性选择判断机制，错误风险选择结果控制机制。
以退款为例，“签收是否超过 7 天”由程序计算；“用户是否表达了退款意图”可以交给 AI；“5000 元退款是否批准”需要人工或严格的确定性系统确认。
二、四种建设模式，各自解决什么问题
完成任务分类后，可以根据结果用途、确认责任和执行方式，选择四种常见的系统建设模式。
1. 纯传统软件：规则明确，结果必须稳定
这类任务可以使用公式、规则或状态机表达。订单金额计算、库存扣减、权限校验、支付入账和业务状态流转，都属于典型场景。
传统代码可以稳定、低成本完成时，引入模型会增加调用成本、响应延迟和结果波动。模型也不应承担数据库约束、事务控制和精确金额计算。
2. AI 输出直接使用：允许差异，错误容易修复
文章标题建议、头脑风暴、文案初稿、普通摘要和学习问题讲解，都需要语言理解或内容生成，也没有唯一答案。
这类结果通常只用于展示，不会直接修改资金、账户和业务数据。系统仍可以检查输出格式、敏感内容、长度、空结果和明显异常，但内容判断主要来自 AI。
一旦结果会自动对外发布、影响用户权益或触发业务动作，就需要增加软件校验或人工确认。
3. AI 输出、人工确认：AI 提建议，人承担责任
高金额退款、合同风险审查、对外邮件和财务报告解读，既需要 AI 处理大量信息，也需要有人对最终结果负责。
有效的人工确认不能只放一个“确认”按钮。审核界面还要展示 AI 建议、数据来源、判断依据、拟执行动作、影响对象和风险提示，并提供修改、拒绝和补充信息入口。
这类模式是否值得采用，可以比较两种成本：人工从头完成任务的成本，以及人工检查和修改 AI 结果的成本。如果两者接近，AI 很难带来明显效率提升。
4. AI 与软件结合：AI 判断，软件校验和执行
当任务既需要语义理解，又要读取实时业务数据或触发操作时，AI 必须进入业务系统。
AI 负责语义判断，并且判断结果能够被业务规则校验时，适合采用这种模式。AI 可以识别用户意图、提取字段和生成工具参数；业务软件继续检查身份、权限、金额、状态、幂等和审批条件。校验通过后自动执行，校验失败则重试、补充信息或转交人工。
客服工单分类、发票字段提取、邮件自动分派和低金额退款，都适合采用这种模式。
同一个产品往往会同时使用四种模式：退款期限由程序计算，退款意图由 AI 判断，低金额退款由软件校验后自动处理，高金额或规则例外交给人工审批。
一个产品可以混合四种模式，每个任务分别选择合适的判断和控制机制。
三、模式选定后，再决定 AI 接入业务多深
四种建设模式确定了程序、AI 和人工怎样分工。进入系统设计后，还要决定 AI 与业务软件连接到什么程度。
从轻到重，可以分成三种互动方式。
1. AI 返回结果
软件输入 → AI 分类、提取或生成 → 软件接收结果这种方式适合文本分类、字段提取、摘要和内容生成。任务通常只需要一次或少量模型调用，未必需要完整的 Agent 框架。
2. AI 调用业务工具
用户请求 → Agent 判断 → 调用业务 API → 读取结果 → 继续处理当 AI 需要查询订单、读取物流或创建售后申请时，需要 Harness 管理工具选择、参数、状态、错误和终止条件，业务系统负责权限校验和实际执行。
3. AI 参与长流程
业务事件 → 工作流 → Agent 节点 → 软件节点→ 人工节点 → Agent 节点 → 业务执行
售后处理、信贷审核和复杂运营任务包含多个阶段、分支和人工节点，需要任务编排、Checkpoint、中断恢复和完整运行记录。
互动方式越深，系统需要承接的运行职责越多。单次结果不必套用完整 Agent，工具型任务需要 Harness，长流程再增加任务编排和恢复机制。
建设模式决定谁判断、谁确认、谁执行；互动深度决定系统需要多少运行组件。
四、自动化范围要用真实结果逐步扩大
同一个系统可以根据任务风险动态选择自动或人工。
金额只是一个因素。操作是否可逆、信息是否完整、是否命中业务例外、影响范围和系统状态，也会改变处理方式。模型给出的置信度可以作为参考，不能单独决定是否绕过人工。
对于准备提高自动化程度的任务，可以采用一条渐进路线：
影子运行AI 产生结果，但不影响业务↓人工确认AI 建议，人决定是否采用↓规则校验后自动执行低风险任务自动化，异常转人工↓风险分级自动化不同风险采用不同处理方式
每个阶段都要保存 AI 输出、人工决定、两者差异、业务执行结果、错误类型和人工处理成本。这些记录用来判断系统能否进入下一阶段。
产品经理可以用七个问题检查自己的方案：
任务能否用规则稳定解决？ 是否需要理解自然语言、图片或复杂文档？ 错误会造成什么后果？ 操作是否可逆？ AI 输出是否容易验证？ 是否已有评测、监控和异常接管机制？ AI 只需返回结果，还是需要调用工具、参与长流程？
选对建设模式之后，Prompt、RAG、Harness 和工作流才有清楚的建设范围。
规则交给软件，语义交给 AI，责任交给人，执行权限留在业务系统。
你的项目现在更接近哪种建设模式？下一步准备提高哪一部分自动化程度？欢迎在评论区聊聊，也可以把这篇转给正在做 AI 项目方案的同事。