企业官网建设流程全解析

别急着上 Agent：如何为 AI 应用选择合适的工具

适用读者：AI 产品经理、应用开发者、技术负责人
核心观点：AI 应用选型不是寻找“最强工具”，而是根据任务的复杂度、不确定性与性能约束，选择成本最低、稳定性最好且足够完成任务的方案。

模块一：选择困难——现实开发中，究竟该用哪种工具？

本模块要回答的问题

为什么 AI 应用开发的难点，正在从“怎么实现”变成“选择什么实现”？

今天开发一个 AI 应用，我们面前通常有四类工具：

• Prompt（提示词）：像一把美工刀，轻巧、直接，适合完成简单而明确的任务。
• Workflow（工作流）：像一条流水线，把稳定步骤串联起来，适合标准化生产。
• Single Agent（单智能体）：像一个全能工匠，可以根据现场情况自主选择工具和调整路径。
• Multi-Agent（多智能体）：像一支专业施工队，通过分工协作处理复杂项目。

它们并不是简单的“低级到高级”。方案越复杂，能力上限可能越高，但调用成本、响应延迟、调试难度和失控风险也会同步增加。

因此，真正要问的不是“Agent 很强，我们要不要用”，而是：

这个任务究竟需要多复杂的工具？它包含多少不确定性？现实约束又允许我们付出多少成本？

接下来，我们用 C.U.P. 三个标准回答这个问题：

• C：Complexity，复杂度
• U：Uncertainty，不确定性
• P：Performance Constraints，性能约束

模块二：标准一——复杂度（Complexity）

复杂度描述的是“事情有多少层”，可以从三个方面判断。

1. 交互复杂度

• 低：单轮输入、单轮输出，例如翻译、分类、改写。
• 高：需要追问、多轮交流、读取文件或持续维护任务状态。

2. 依赖复杂度

• 低：只依赖模型本身即可完成。
• 高：需要查询数据库、调用工具，并在多个系统间传递结果。

3. 过程复杂度

• 低：一个步骤即可完成。
• 高：存在多个相互依赖的步骤，还可能出现分支、回退和重试。

可以用以下问题快速评估：

• 完成任务需要几轮交互？
• 需要使用多少个工具或数据源？
• 是否存在多个前后依赖的步骤？
• 中间结果是否会改变后续处理方式？
• 失败后是否需要诊断、重试或更换路径？

复杂度越高，单纯依靠一条提示词就越难维持稳定性。但要注意：步骤多不等于一定需要 Agent。如果步骤可以提前确定，Workflow 往往更加可靠。

模块三：标准二——不确定性（Uncertainty）

不确定性是 C.U.P. 模型中最关键的维度，也是判断是否需要 Agent 的核心依据。它可以分成三类。

1. 输入不确定性

• 边界清晰：输入字段、格式和内容范围明确。
• 边界模糊：用户表达开放、信息缺失，输入类型无法提前穷举。

2. 过程不确定性

• 固定路径：每一步都可以提前画进流程图。
• 未知路径：系统需要根据中间结果自主决定下一步。

3. 目标不确定性

• 标准明确：存在清晰答案或可量化的验收条件。
• 标准模糊：结果需要解释、权衡，甚至要与用户共同澄清目标。

由此可以得到一个实用判断：

Workflow 擅长执行已知路径，Agent 擅长探索未知路径。

例如，“OCR → 验真 → 计算金额”虽然包含多个步骤，但路径固定，更适合 Workflow；而“搜索信息 → 判断缺口 → 调整策略 → 重写方案”的下一步取决于中间结果，更适合 Agent。

评估时不要凭感觉。应选取真实样本，记录边界外输入、路径分支和目标争议出现的频率。

模块四：标准三——性能约束（Performance Constraints）

性能约束决定方案能否落地。它不是普通的加分项，而是一组“一票否决”的门槛。

项目应在选型前写清 Go / No-Go 条件：

• 若 P95 延迟超过[阈值]，方案否决。
• 若单次综合成本超过[阈值]，方案否决。
• 若任务成功率低于[阈值]，方案否决。
• 若无法满足[安全或合规要求]，方案否决。

多一步推理、多一次工具调用、多一个 Agent，都会产生真实成本。架构设计不能只看“AI 能不能做到”，还要看它能否在预算、速度和可靠性边界内持续做到。

模块五：综合决策——Prompt、Workflow 还是 Agent？

将三个标准放到同一个决策框架中，可以得到一张简化的选型矩阵：

实际决策时，可以遵循以下顺序：

1. 先检查 P：排除不满足延迟、成本、安全与合规要求的方案。
2. 再评估 C：确认任务需要多少步骤、工具和上下文。
3. 重点判断 U：看系统是在执行固定路径，还是必须自主探索。
4. 从最简单方案开始验证：Prompt 不足再考虑 Workflow，Workflow 无法覆盖动态路径再引入 Agent。
5. 最后才考虑多智能体：只有专业分工或并行处理带来的收益明显大于协调成本时，才使用 Multi-Agent。

模块六：架构的智慧——通过降低不确定性降低应用成本

很多团队面对复杂任务时，第一反应是增加模型能力、工具数量或 Agent 数量。但更有价值的架构思路，是主动改造问题本身：

不要只提升系统处理不确定性的能力，也要设法减少系统必须处理的不确定性。

降低不确定性，可以从三个层面入手。

1. 限制输入不确定性：先判断“这是不是我的问题”

面对用户的开放输入，系统不必尝试回答一切。更稳妥的做法，是先按照业务能力对问题进行分类：

• 属于已支持业务类型的问题，进入对应的处理流程并正常回答。
• 不属于任何已支持类型的问题，统一归入Other。
• 对Other类问题直接回复“暂不支持”，或引导用户选择当前可用的服务范围。
• 对信息不足但仍在业务范围内的问题，只追问完成任务所必需的字段。

2. 限制过程不确定性：只承诺固定路径能够解决的问题

• 完成输入分类后，可以为每一类受支持的问题配置固定处理路径。例如：

发票上传 → OCR 识别 → 字段校验 → 发票验真 → 金额计算 → 返回结果

系统只返回这条固定路径能够可靠产出的结果。如果输入无法进入既定流程、关键步骤失败，或者任务需要路径之外的能力，就明确回复“暂不支持”或转交人工，而不是让 Agent 临时寻找未知路径。

固定路径的价值在于：

• 每一步的输入、输出和责任边界都可以定义。
• 异常情况可以提前设计兜底策略。
• 结果可以重复测试，问题也更容易定位。
• 延迟、成本和成功率能够被稳定度量。

这相当于用 Workflow 收缩 Agent 的自由探索空间：系统不追求“任何问题都尽量试一试”，而是承诺“支持范围内的问题稳定解决，范围外的问题明确拒绝”。

3. 限制目标不确定性：用固定指标建立用户心智

目标不确定往往来自用户与系统对“好结果”的理解不同。与其让用户期待一个无所不能的 AI，不如主动建立清晰的产品心智：告诉用户系统擅长什么，并用少数固定、明确的指标衡量产出。

例如，可以先选择三到五个核心指标：

• 正确性：关键字段准确率达到[指标]。
• 完整性：必填信息覆盖率达到[指标]。
• 时效性：P95 响应时间不超过[指标]。
• 一致性：相同输入的结果一致率达到[指标]。
• 可用性：业务范围内任务成功率达到[指标]。

这些指标既是内部验收标准，也是对外建立预期的方式。用户逐渐形成的心智应该是：系统会在明确范围内，按照一套稳定标准交付结果；无法满足标准时，它会明确说明暂不支持，而不是给出一个看似合理但无法保证的答案。

这样做的结果是：开放输入被收敛为有限分类，未知过程被收敛为固定路径，模糊目标被收敛为明确指标。原本需要 Agent 自由探索的任务，便可能转化为一个稳定、可测量的 Workflow。