AI Agent Field Notes
← 返回文档集

AI 项目开发建议

目标：把一个 AI 想法从“模型 Demo”推进到“有人持续使用、结果可验证、成本可接受的产品”。

一句话结论

不要先选模型或框架，先选一个高频、结果可判断、人工流程确实昂贵的问题；用最小可用工作流验证价值，再逐步增加 Agent、工具和自治。

1. 先判断项目值不值得做

一个值得做的 AI 项目通常同时满足：

先问这 6 个问题

  1. 谁在什么场景下遇到什么具体问题？
  2. 现在不用 AI 是怎么完成的，最贵的环节是什么？
  3. 用户愿意为什么结果付费或持续使用？
  4. 什么叫“做对”？能不能写成测试集或验收规则？
  5. 错了会造成什么损失，谁来发现和兜底？
  6. 第一周能不能用 1 个模型、3 个工具以内做出可用版本？

如果前四个问题答不清楚，优先做用户访谈和人工流程拆解，不要先搭 Agent 平台。

2. 从工作流而不是聊天框开始

一个产品化 AI 项目最好描述成：

触发条件 → 输入资料 → AI 判断/生成 → 工具行动 → 验证结果 → 人工/系统决策 → 留下记录

例如“研究助手”不是“一个能聊天的机器人”，而是：

用户给出问题
→ 搜索并筛选来源
→ 提取证据
→ 交叉核验
→ 生成带引用的结论
→ 检查引用是否支持结论
→ 返回报告与待确认项

产品价值通常来自完整流程的结果，而不是模型回答本身。

3. MVP 的正确顺序

阶段 A：人工辅助原型

先用人工挑选资料、人工检查结果，验证用户是否真的需要最终产物。此阶段可以使用模拟工具和固定数据，但必须明确标注。

阶段 B：单模型 + 少量工具

阶段 C：固定工作流

把稳定步骤写成程序流程，例如提取 → 分类 → 检索 → 生成 → 校验。固定流程通常比让 Agent 自由规划更容易测试、解释和控制成本。

阶段 D：按需加入 Agent

只有当步骤数量、工具选择或任务路径无法预先确定时，才让模型动态规划。对自治循环设置最大步数、预算、超时和停止条件。

阶段 E：生产化

补齐身份、权限、审计、监控、重试、回滚、人工审批、成本控制、数据保留和故障处理。

4. 架构分工：模型不要承担所有责任

模型负责

程序负责

人负责

5. 数据与上下文

不要把“拥有很多资料”误认为“拥有可用数据”。优先建设：

对长任务，把长期规则、用户偏好、当前进度、证据和临时草稿分开存储。不要把所有东西堆在一个无限增长的对话里。

6. 评估先于优化

建立最小评估集

第一版不需要几千条数据，但要覆盖：

至少测这些指标

评估顺序

先看最终结果
→ 再看工具调用和中间步骤
→ 找到最常见失败模式
→ 修改提示/工具/流程
→ 重新跑同一批任务

不要只用一条漂亮 Demo 判断项目成功，也不要只追求模型 benchmark 分数。

7. 工具与集成设计

每个工具都应该明确：

读工具与写工具分开。搜索、读取、草拟可以自动执行；发送、发布、付款、删除、改权限默认进入审批流。

8. 什么时候做多 Agent

只有在以下情况出现时才拆多 Agent：

不要为了“看起来先进”而拆多个 Agent。多 Agent 会增加协调成本、延迟、状态同步、错误传播和调试难度。

9. 安全与可靠性基线

涉及外部系统时，至少准备：

AI 系统的“可解释”不等于模型写了一段解释。更重要的是：能查到它看了什么、调用了什么、改变了什么，以及结果如何被验证。

10. 成本控制

成本优化顺序建议是：

  1. 减少无效任务和无意义的 Agent loop；
  2. 缩短上下文，按需检索；
  3. 使用缓存和结构化中间结果；
  4. 简单任务路由到更便宜模型；
  5. 对昂贵工具和深度推理设置预算；
  6. 最后才考虑模型微调或更复杂的基础设施。

每个任务记录 token、工具调用数、重试数、耗时和最终成本。没有成本数据，就无法判断产品是否能规模化。

11. 生产发布检查清单

产品

工程

安全

运营

12. 最小可行项目模板

项目名称：
目标用户：
高频任务：
现有人工流程：
AI 负责：
程序负责：
第一版只允许使用的工具：
成功标准：
必须人工审批的动作：
评估集规模：
单任务成本上限：
上线前验证方式：
失败后的备用流程：

推荐阅读来源

最后判断

一个 AI 项目真正的护城河通常不是“接了哪个模型”，而是：