智能体试点的停止条件，不能等到项目“做不下去”时才临时决定。若没有事先写明什么结果算成功、什么情况必须暂停，团队很容易把每次失败解释为数据不足、功能未完善或用户还没习惯，最终让试点无限延长。
设定条件时，应从真实工作流出发，先记录任务频率、现有处理成本、验收标准和出错后果，再明确智能体必须达到的最低交付要求。指标应针对任务结果，而非回答是否流畅：代码任务看测试与审核结果，文档任务看完整性、准确性和返工情况。还要把人工审核与修正计入成本，否则看似自动化的流程，可能只是把工作转移给试点团队。
把停止条件写成可观察的信号
试点开始前，至少要约定观察周期、数据记录方式、责任人，以及以下几类退出信号：
- 需求不成立：用户很少重复使用，或只有口头认可，没有真实投入、预算或续用意愿。
- 结果不可靠：输出无法稳定达到共同确定的验收标准，常见错误也没有可行的补救方式。
- 经济性不成立：模型与工具、人工审核、交付和支持等成本，使单次交付难以形成可接受的贡献。
- 无法复制：每次交付都依赖创始人或专家盯办，换一个客户就需要大量定制。
停止不等于只能放弃。若用户确有需求、但质量或成本不达标，可以缩小任务范围、改变交付方式后再验证；若需求本身缺乏重复性，继续堆功能通常不会解决根因。每次调整都应形成新的假设和退出条件，避免把试点变成没有边界的长期项目。
最重要的是区分“尚未达到标准”和“标准本身不清楚”。前者可以继续验证，后者应先暂停扩张、与实际使用者重新定义验收方式。停止条件不是对智能体能力的预判，而是让团队能够依据证据及时止损、转向或继续投入。