立项书先回答为什么要做
AI Agent项目立项首先需要明确现有流程的具体问题：员工查资料慢、客服重复查询多，还是工单信息不完整导致返工。把问题写成可观察的事实，说明涉及人员、任务发生量和当前处理方式，避免以“建设智能化能力”代替业务目标。
随后解释为什么已有系统配置、搜索工具或规则流程无法充分解决。模型能处理非结构化语言与资料，并不意味着任何流程都需要Agent；立项依据应包含替代方案及选择理由。
基线需要覆盖完整处理过程
从授权历史记录或现场观察中抽取样本，记录任务量、平均处理时间、错误与返工情况。不同难度任务最好分组，防止试点只挑简单问题，与原流程的混合平均值比较。
例如，售后问题处理可能包含资料查找、沟通确认、系统登记和主管复核。若智能体仅缩短资料查找，应只计算这一部分的变化，同时加回使用系统和复核答案的时间，不能把整段处理时间全部算成节省。
将试点范围写成可签字的边界
明确首批用户、业务入口、资料范围、允许调用的工具与禁止动作。写清哪些步骤由人工完成、遇到异常交给谁，以及哪些新需求需要重新评估。试点范围宜足够小，但必须覆盖一个可以观察结果的完整任务。
交付物可包括场景说明、评测集、知识处理规则、可运行原型及试运行报告。只有演示页面而没有数据、权限与评测约定，很难为下一阶段投资提供依据。
投入产出如何计算才可信
可先用“有效任务量×每项任务净节省时间×相应人工时间成本”估算直接收益，再减去模型、基础设施、复核、维护与培训成本。任务量应扣除没有采用结果、转人工及失败重做的部分。
销售转化提升、客户满意度等收益受多种因素影响，宜单列为待验证假设，不要直接全部归因于AI。内部时间节省也不等于立刻减少现金支出，应区分释放产能与实际财务收益。
把收益假设写成可验证记录
以内部政策查询试点为例，记录“现有资料定位时间较长”这一假设，并先观察若干实际任务，分别测量查找、阅读与核对。上线后采用相同类型问题比较，不能用新员工的原始时间对照资深人员使用AI的时间。若答案生成很快但复核更久，应如实计入；若资料集中整理本身已经改善搜索，也应区分这部分收益与模型的增量价值。
- 基线与试点的任务难度是否可比。
- 是否计入人工复核及资料维护。
- 下一阶段资金对应什么交付证据。
- 哪种结果会触发调整或停止。
用阶段门代替一次性押注
技术验证阶段检查最关键的不确定性，例如资料是否支持回答、接口是否可用。试点阶段验证真实用户能否完成任务，上线阶段再补齐权限、监控、容量和维护安排。每个阶段都应写明继续、调整或停止的条件。
立项评审可以要求业务负责人确认价值口径、IT负责人确认集成与部署条件、数据负责人确认资料可用范围。决策材料要保留假设和不足，让后续评估能够解释结果，而不是只留下一个承诺很高的收益数字。