很多 AI 项目的第一版都令人兴奋：接入模型、放入几份文档、做一个聊天页面，就能回答不少问题。但当它进入真实业务，团队很快会遇到另一组问题：回答是否有来源，工具调用失败怎么办，谁有权看到哪些数据，效果如何验收，模型升级后是否会退化。
这些问题并不意味着模型能力不够，而是说明项目已经从“模型演示”进入“系统工程”。
先定义任务，不要先选择框架
Agent 项目的起点应该是一个可以观察和验收的业务任务。例如：
- 从已授权的制度与产品资料中回答客户问题，并附上可核验来源；
- 根据结构化指标发现广告异常，生成供运营人员确认的调整建议；
- 把会议材料、录音和历史待办整理成决策与后续任务。
任务越具体，后续的数据范围、工具权限、评测样本和人工审核节点就越容易确定。反过来，如果需求只有“做一个智能助手”，项目通常会在不断增加功能后失去清晰边界。
把 Agent 拆成可检查的链路
一个可交付的 Agent 通常至少包含五个部分：
- 上下文：模型需要看到什么，不应该看到什么。
- 知识：资料如何切分、检索、更新和引用。
- 工具：哪些动作可以自动执行，哪些必须由人确认。
- 状态：多轮任务进行到哪里，失败后如何恢复。
- 评测：怎样判断答案正确、过程合规、结果对业务有用。
这些部分应该可以分别观察和测试。否则，当最终结果不符合预期时，团队只能反复修改 Prompt，却无法确认问题究竟发生在哪一层。
评测必须在上线之前出现
评测不是项目结束后的打分表，而是开发过程中的导航系统。一个实用的最小评测集可以来自真实业务问题，并覆盖：
- 高频正常请求；
- 信息缺失和表达模糊的请求；
- 工具超时、检索无结果等异常；
- 越权、隐私和高风险决策边界；
- 用户明确拒绝或要求转人工的场景。
除了最终回答，还要检查检索结果、工具参数、状态变化和引用是否正确。这样才能知道优化应该发生在数据、编排、工具还是模型层。
交付的是可持续迭代的系统
企业 AI 项目不应该以“页面能跑起来”作为终点。更可靠的交付至少应包含：
- 明确的能力与风险边界；
- 可复现的测试与验收样本；
- 调用链路、错误和成本的基础观测；
- 数据、Prompt、模型和工具的版本记录；
- 出错后的降级、重试与人工接管方式；
- 让业务和技术团队都能继续维护的文档。
模型会快速变化，但清晰的任务、受控的工具、可复现的评测和可靠的工程边界不会过时。它们决定了一个 AI Demo 能否真正走进业务。