夜雨聆风过去两年，大多数 AI 产品其实只有一条简单链路：用户输入 → 调用模型 → 返回结果。
这种模式在 demo 阶段很好用。一个 API 就能跑通产品逻辑，工程复杂度也很低。
但只要进入真实业务场景，事情会迅速变样。用户不再只是问一个问题，而是希望 AI 去“完成一件事”：查资料、写代码、整理数据、调用系统、再根据结果继续推理。
这时，一次请求背后可能是几十次模型调用。
AI 产品也从“接入一个模型”，变成“运行一套系统”。
在这种背景下，一套新的 AI 工程打法逐渐成形：Tiger Team、Evals，以及围绕 Agent 工作流构建的系统架构。
从一次调用，到一条 Agent 工作流
最早的 LLM 应用基本是单轮推理。
系统只做三件事：接收输入、调用模型、返回文本。
而在 Agent 架构里，模型只是调度者。
一个典型任务可能包含这样的流程：
模型先规划步骤，然后调用搜索或数据库；根据结果生成代码；执行代码后再继续推理；必要时再次调用工具。
在很多实现里，这种流程会通过框架管理，例如利用工具调用机制或工作流框架（如函数调用机制、Agent 编排框架等）来控制每一步执行。
当流程循环起来，一次用户请求可能触发十几次甚至几十次推理。
这时系统瓶颈就完全不同了。
不再是“模型够不够聪明”，而是：
每一步调用要多久 上下文要传多大 工具调用是否稳定
如果每一步多 100 毫秒，整个任务就可能慢上几秒。
在 Agent 系统里，这种差距会直接影响用户是否愿意继续使用产品。
为什么很多 AI 项目从 Tiger Team 开始
工程架构变化的同时，团队结构也在变化。
不少公司在内部推动 AI 项目时，并没有直接交给原有研发体系，而是先成立一个小规模 Tiger Team。
这类团队通常只有几个人：产品负责人、几名工程师，再加一名熟悉模型或数据的成员。
规模小是刻意设计的。
原因很现实——AI 项目的早期阶段高度不确定。
一个场景到底能不能被模型解决，往往需要大量快速试验：Prompt 调整、工具接入、数据清洗、流程重构。
如果完全按照传统软件流程推进，需求评审、技术评审和发布流程会拖慢探索速度。
Tiger Team 的任务只有一个：
尽快回答一个商业问题——AI 能不能把这个问题解决到用户愿意付费的程度。
一旦验证成立，再把能力平台化，交给更大的工程团队。
很多企业内部成功的 AI 项目，几乎都是这样起步的。
没有 Evals，团队其实不知道模型有没有变好
传统软件测试关注的是“功能是否正确”。
但在 AI 系统里，输出本身就是概率性的。模型更新一次，回答可能变好，也可能变差。
这就是为什么越来越多团队开始建立 Evals 体系。
一个常见做法是三层评估。
第一层是离线测试。
团队准备一组典型任务，例如客服问答、代码生成或数据分析，然后在每次模型或 Prompt 更新后重新跑一遍，确认效果没有明显退步。
第二层是自动化评估。
系统用规则或辅助模型去判断输出质量，例如是否包含关键字段、是否遵循指定格式。
第三层是线上实验。
把一部分真实流量导向新版本，观察用户行为，例如完成率、点击率或任务成功率。
很多 AI 项目卡住，并不是因为模型能力不够，而是团队缺乏一套稳定的评估机制。
没有 Evals，优化就变成了主观感觉。
Agent 系统真正的难题：延迟和状态
当系统进入多轮 Agent 循环后，一个经常被忽视的问题会浮现：数据传输。
很多应用仍然采用最简单的方式——每次调用模型都重新发送完整上下文。
在简单问答场景里问题不大，但在复杂工作流中，上下文会不断增长。
结果就是：
网络传输增加，推理时间上升，成本也在放大。
一些团队开始改用“状态化执行”。
做法很直接：把上下文状态保存在服务端，模型只接收必要的信息，而不是整段历史记录。
在多轮任务中，这种优化可以显著减少数据传输，并缩短执行时间。
当一次任务包含几十轮调用时，这类底层优化会被不断放大。
很多团队在产品上线后才意识到：真正影响用户体验的不是模型参数，而是系统架构。
AI 工程变化背后的创业机会
当开发方式发生变化，新的基础设施需求也会随之出现。
目前可以看到三类明显的机会。
第一类是 Agent 开发框架。
这类工具帮助团队管理任务规划、工具调用、上下文状态和执行流程，让复杂工作流可以被稳定运行。
第二类是 Evals 平台。
企业需要持续评估模型表现，因此需要专门的工具来管理测试数据、运行评估并跟踪指标变化。
第三类是 AI 基础设施。
例如推理加速、上下文缓存、低延迟通信、任务调度等能力。
这些产品的客户并不是普通用户，而是正在构建 AI 产品的团队。
换句话说，最早付费的一批人其实是开发者和企业。
如果一项工具能让 AI 工作流快 20%，或显著降低推理成本，企业通常愿意为此买单。
如果你正在做 AI 产品，下一步应该怎么推进
很多团队仍然把注意力放在模型选型上：用哪个模型、参数多少、成本多少。
但随着 Agent 系统普及，真正拉开差距的往往是工程体系。
更现实的推进路径通常是三步。
第一步，组建一个小型 Tiger Team，用最短时间验证核心场景是否成立。
第二步，尽早建立最基础的 Evals，即使只是几十个测试任务，也比完全没有评估体系要可靠。
第三步，从一开始就按系统思路设计架构，而不是把模型当作一次性 API。
AI 产品的竞争，正在从模型能力转向工程能力。
谁能把模型、工具和数据组织成一套稳定运行的系统，谁就更有机会把 AI 变成一门长期生意。
