近期，团队在讨论 AI Coding 时，经常会遇到这样问题：
给模型一句 Prompt：
text
你是一名前端开发工程师。
请帮我生成一个 React 列表页面。模型很快可以给出 JSX、样式、分页逻辑，甚至一套看起来还不错的 TypeScript 类型。可如果把任务换成：
在现有项目中新增一个违规处置列表页面，并满足业务规则、权限要求和团队工程规范。验收对象就不再是"有没有生成一段代码"，而是：
- 需求有没有理解对；
- 已有组件有没有复用；
- 接口字段和权限规则有没有接错；
- 修改是否符合仓库规范；
- lint、测试和构建能不能通过；
- 失败之后能不能定位并修正。
❓模型已经会写代码，为什么任务还是不能直接交付？
如果问题只在模型，我们应该继续优化 Prompt、扩大上下文，或者换一个更强的模型。但从上面的验收项可以看到，缺口不只发生在生成环节： 模型还需要取得项目事实、执行外部动作、根据结果继续推进，并在越过风险边界前停下来。
本文就从这个问题开始：模型能力，要经过哪些环节，才能转化为可交付的企业生产力？
一、真正的差距，不在"能不能生成"，而在"能不能交付"
1. 模型演示和真实任务的条件不同
模型演示通常发生在受控条件下：输入清楚、上下文完整、输出边界明确。真实业务环境却很少这么理想。需求可能存在歧义，文档可能已经过期，工具调用可能失败，权限可能不足，执行到一半还可能需要人工确认。
因此，模型在单次测试中表现很好，只能证明它具备某一步所需的理解或生成能力，不能直接证明整个应用可以稳定交付任务。
2. 从能力到交付，中间至少有三层
本文用三个层次拆解这段距离：
| 层次 | 主要回答的问题 | 页面开发中的例子 |
|---|---|---|
| 模型能力层 | 模型能否做好当前步骤的理解、推理或生成？ | 分析需求、生成 JSX、解释报错 |
| 任务闭环层 | 系统能否取得事实、执行动作并根据反馈继续推进？ | 读取 PRD、查询组件、修改文件、运行测试 |
| 工程保障层 | 整个过程能否被评价、观察、约束、恢复和改进？ | 权限控制、变更审计、失败恢复、质量评测 |
Agent 的官方文档也体现了类似的系统边界：它被描述为能够规划、调用工具、与专门角色协作，并保持足够状态来完成多步骤工作的应用。^1^ 关键词不是某个模型名称，而是应用、工具、状态和多步骤工作。
由此可以先得到一个判断：模型能力影响系统理解与推理的上限，任务闭环和工程保障决定这种能力能否稳定转化为业务结果。
二、一个页面开发任务，为什么不是一次 Prompt？
1. 先区分"生成一步"和"交付任务"
如果任务只是生成一个独立组件、把 JavaScript 改成 TypeScript，或者解释一段报错，单次模型调用往往就是成本最低、响应最快的方案。Prompt 没有失效，问题在于我们有时会把"模型能生成任务中的某一步"，误认为"模型能交付整个任务"。
以违规处置列表页面为例，模型只看一句需求时，可以根据通用知识猜出页面结构：
- 搜索表单；
- 数据表格；
- 分页；
- 处置按钮；
- 加载和空状态。
这些内容看起来合理，却还不能证明它适配当前项目。项目使用哪套组件库？筛选条件来自哪里？处置按钮受什么权限控制？分页字段叫 pageSize 还是 size？这些事实不在模型的通用知识里。
2. 企业交付面对的是任务链
下面的步骤是本文为说明问题构造的工程场景，不代表每家公司都采用同一套研发流程。
| 任务要求 | 单次模型调用 | 完整应用系统 |
|---|---|---|
| 理解需求 | 只能依据输入中的文字 | 可读取 PRD、补充材料并请求澄清 |
| 复用组件 | 可能按通用经验生成 | 可搜索代码仓库和组件文档 |
| 接入接口 | 容易猜测字段和返回结构 | 可读取 API 定义并校验类型 |
| 遵循规范 | 依赖 Prompt 是否完整列出 | 可加载仓库规则、模板和示例 |
| 验证结果 | 生成后即结束 | 可运行 lint、测试和构建 |
| 处理失败 | 等待用户再次提问 | 可读取错误反馈并决定修正或暂停 |
| 控制风险 | 难以仅靠文字保证 | 可限制工具权限并设置人工确认点 |
差距主要来自三类复杂性。
-
多步骤。 后一步依赖前一步的结果。接口尚未确认，代码生成得再快，也可能只是更快地产生返工。
-
多系统。 真实信息分散在需求文档、代码仓库、组件平台、接口文档和 CI 环境中。模型并不会天然拥有这些数据与权限。
-
持续判断。 搜索不到组件怎么办？测试失败后应该修改实现还是补充配置？发现需求和接口冲突时是否继续？每一次环境反馈都可能改变下一步。
模型产生结构化调用，真正的操作由应用或平台执行。^2^ 这意味着"模型建议调用什么"和"系统是否允许、如何执行"是两件事。任务闭环来自模型决策与确定性执行的配合，而不是把数据库或仓库权限直接交给模型。
三、从生成响应到完成任务，中间多了一个闭环
1. 单次模型调用：输入到响应
最简单的 LLM 应用可以表示为：
它适合边界清楚、无需持续访问外部环境的任务，例如总结、改写、分类或生成一个独立代码片段。系统的核心产物是一次响应。响应返回后，本轮工作结束。
2. Workflow：用固定路径组织多个步骤
当任务可以稳定拆成若干步骤时，可以用 Workflow 把模型和工具串起来。
一种常用的架构区分是：Workflow 由预定义代码路径编排 LLM 与工具；Agent 则由 LLM 动态决定过程和工具使用。^3^
例如，一个固定的页面生成流程可以是：
步骤提前确定，失败分支也可以在代码中写清楚。这类任务使用 Workflow，通常比开放式 Agent 更容易测试和维护。
3. Agent：根据环境反馈决定下一步
如果无法预先知道需要查哪些文件、调用几次工具、遇到错误后走哪条路径，就更适合考虑让模型参与过程决策。
一个公开、可观察的 Agent 执行循环可以概括为：
Agent 需要从工具结果、代码执行等环境反馈中取得可核验的事实，并据此判断进展；遇到检查点或阻塞时，可以返回给人处理。^3^ 普通 ChatBot 或单轮调用即使使用了 LLM，如果模型并不控制任务的后续执行，也不属于这里讨论的 Agent。^4^
4. 三者不是新旧替代关系
| 形态 | 路径由谁决定 | 适合场景 | 主要代价 |
|---|---|---|---|
| 单次调用 | 一次输入直接得到响应 | 边界明确、无需外部动作 | 难以完成多步骤任务 |
| Workflow | 代码预先定义 | 步骤稳定、强调一致性 | 对开放变化适应有限 |
| Agent | 模型在边界内动态选择 | 步骤难预知、需要环境反馈 | 成本、延迟和错误累积风险更高 |
Agent 不是 Prompt 的"高级版"，Workflow 也不是"低级 Agent"。它们对应不同确定性的任务。工程上应从最简单的可行方案开始，只有当动态决策确实改善结果时，才引入多步骤 Agent。^3^
四、从任务闭环到生产系统，还缺什么？
第三节解释了 Agent 如何借助环境反馈形成任务闭环。但闭环能够运行，不等于任务已经具备生产可用性：执行可能中断，所有接口也可能正常返回，最终结果却仍然偏离用户目标。
1. 从一次 Response 到一次 Run
普通模型调用的核心对象是一次 Request/Response，Agent 的工程对象则更接近一次 Task 或 Run。一次 Run 可能包含多次模型调用和工具执行，也可能在提交代码等节点暂停，等待确认后再继续。
因此，应用需要用 State 记录目标、已完成步骤、工具结果、等待中的输入以及恢复位置。循环、状态、可恢复审批和人工复核共同围绕一次 Run 工作。^1^ 任务只有在中断后可以恢复、失败后可以继续处理时，才算拥有可管理的生命周期。
2. 接口成功不等于任务成功
传统服务关注错误率、延迟、吞吐量和资源使用，这些指标在 AI 应用中仍然重要，却不能单独回答"任务完成得好不好"。一次 Agent 运行可能所有 API 都返回 200，最终却读取了过期文档，或者生成的代码能够构建，却遗漏了权限分支。
这类系统具有非确定性和复杂性，观察范围需要覆盖模型交互、工具使用、执行路径、状态变化、安全和质量，而不仅是接口是否成功。^5^ 日志和 Trace 也需要纳入检索来源、工具调用、权限与执行结果，并与评测和治理连接。^6^
| 工程问题 | 对应能力 | 页面开发中的典型信号 |
|---|---|---|
| 能否评价 | Evaluation | 需求覆盖、测试结果、工具选择是否合理 |
| 能否观察 | Logs / Metrics / Trace | 哪一步失败、调用次数、延迟和成本 |
| 能否约束 | Guardrails / 权限控制 | 允许读取哪些仓库、哪些动作需要确认 |
| 能否改进 | 评测集 / 回归机制 | 线上失败能否转成后续测试用例 |
这四类能力把质量判断从"最终文字是否流畅"扩展到任务结果和执行过程。真实失败还应沉淀为评测任务，用于验证后续修改是否引入回归。^7^
3. 自主执行仍然需要风险边界
Human in the loop 不等于每一步都弹出审批框，也不意味着所有动作默认放行。更合适的方式是按风险分层：
- 只读搜索可以在授权范围内自动执行；
- 文件写入限制在指定工作区，提交前展示变更；
- 发布、删除、付款等高风险动作必须人工确认。
遇到阻塞或只有用户才能决定的偏好时，系统也应暂停并请求反馈。^3^ 所谓"自主"，是系统在授权边界内连续推进，同时让人保留监督和干预能力。
这些能力共同构成三层框架中的工程保障层：任务闭环不仅要能运行，还要可管理、可评价、可约束。
五、什么时候需要 Agent，什么时候不需要？
讨论到这里，容易走向另一个极端：既然真实任务需要闭环，是不是所有 AI 应用都应该改造成 Agent？
答案是否定的。Agent 会引入更多模型调用、工具交互和状态管理，也意味着更高的延迟、成本以及错误累积风险。没有明确收益时，增加自主性只是在增加系统复杂度。
1. 把选择收敛为五个问题
前面已经说明三种形态不是新旧替代关系。落到方案设计时，可以把选择收敛为五个问题：
- 一次调用能否可靠完成？ 如果输入和输出边界清楚，不必增加循环。
- 步骤能否预先确定？ 如果路径稳定，优先使用 Workflow。
- 是否必须访问外部事实或执行动作？ 如果不需要，工具和状态可能都是额外负担。
- 能否获得明确的环境反馈？ Agent 需要根据测试结果、工具返回等事实判断进展。
- 收益能否覆盖成本和风险？ 灵活性不是免费的，尤其是高频和高风险任务。
开放问题难以预先确定步骤时，Agent 更有价值；任务路径清晰时，简单调用或 Workflow 往往已经足够。^3^
这五个问题仍然落在前文的三层框架中：先判断模型能不能做好单步工作，再判断任务是否需要动态闭环，最后确认成本和风险是否可控。三层之间有依赖，但不是产品成熟度排行榜。
2. 回到页面开发案例
同一个"生成页面"需求，根据任务范围不同，方案也不同。
| 问题特征 | 推荐形态 | 原因 |
|---|---|---|
| 根据明确字段生成一个表格组件 | 单次调用 | 输入、输出和完成条件都清楚 |
| 按固定模板生成页面并依次运行校验 | Workflow | 步骤稳定，可由代码编排 |
| 在现有仓库中自主查找组件、修改文件、测试并修正 | Agent | 路径依赖环境反馈，难以预先写死 |
| 涉及发布生产或高权限数据修改 | 优先确定性流程；确需 Agent 时增加人工确认 | 高风险动作不应仅由模型动态决定 |
这个判断也能迁移到其他场景。
客服问答可能只需要检索和生成；退款处理需要读取订单、判断规则并调用工具；超过额度的退款还需要人工审批。运营报告可以由固定 Workflow 生成；面对数据异常时，是否允许 Agent 自主扩大查询范围，要看数据权限、反馈质量和风险。
不是所有业务都需要 Agent；一旦系统开始代表用户连续执行任务，就应同步设计与风险相匹配的工程保障。
六、这就是本文所说的 AI 应用工程
回到开头。模型能根据一句 Prompt 生成 React 页面，只证明它具备了任务中的代码生成能力；当系统还要取得上下文、调用工具、保存状态、处理失败、评测结果并控制权限时，建设对象已经从模型扩展为完整的 AI 应用。
广义的 AI Engineering 本来就关注 AI 系统如何走出受控环境。CMU 软件工程研究所（SEI）将它描述为结合系统工程、软件工程、计算机科学和以人为本设计，在复杂、模糊、动态的真实环境中构建 AI 系统的研究与实践领域。^8^
本文讨论的范围更窄：围绕基础模型构建任务闭环，并通过软件工程手段让 AI 应用可运行、可评价、可观察、可约束、可持续改进。
这就是我说的 AI Application Engineering（AI 应用工程）。
它不等于"选一个更强的模型"，也不等于"套一个 Agent 框架"。模型、Prompt、Tool、Workflow、Agent 和平台能力各自处理不同层面的问题。工程工作的价值，在于把它们组合成符合业务目标和风险边界的系统，并用运行反馈持续改进。
总结
这篇文章只需要带走三个判断：
- 模型能力是起点，不是企业生产力本身。
- 从响应到任务，需要上下文、工具、状态和环境反馈构成闭环。
- 从 Demo 到生产，需要评测、可观测性、边界控制与人工协作。
下一篇，我们会进入 Agent 内部，拆解一个任务循环到底如何运行：模型负责什么，工具如何被调用，状态怎样更新，系统又在什么条件下继续、暂停或结束。
Footnotes
-
OpenAI, "Agents SDK", developers.openai.com/api/docs/gu... （official-doc） ↩ ↩2
-
Anthropic, "Tool use with Claude", docs.anthropic.com/en/docs/bui... （official-doc） ↩
-
Anthropic, "Building effective agents", www.anthropic.com/engineering... （official-blog） ↩ ↩2 ↩3 ↩4 ↩5
-
OpenAI, "A practical guide to building AI agents", openai.com/business/gu... （official-blog） ↩
-
Google Cloud, "Agent observability", docs.cloud.google.com/stackdriver... （official-doc） ↩
-
Microsoft Learn, "Observability for Generative AI and agentic AI systems", learn.microsoft.com/en-us/secur... （official-doc） ↩
-
Anthropic, "Demystifying evals for AI agents", www.anthropic.com/engineering... （official-blog） ↩
-
CMU Software Engineering Institute, "AI Engineering", www.sei.cmu.edu/artificial-... （official-doc） ↩