一口三个馍

Appearance

Agent 应用开发：从需求到落地，我会怎么做 ​

我做了十年左右 Java / 全栈和企业业务系统。往 AI 应用、Agent 应用转的时候，最常被问的一句是：

如果今天让你从 0 做一个真正能用的 Agent 应用，你会怎么做？

这篇不讲 Agent 定义，也不讲模型原理。那些在 技术 → Agent。这里只讲我会怎么设计、怎么拆、怎么收口——以及哪些地方我会刻意不做。

1. 我理解的 Agent 应用开发 ​

普通 AI 调用大概是这样：

text
用户 → Prompt → 模型 → 结果

一次调用，一次回答。适合总结、改写、抽取、简单问答。工程上它更像「调用一个会说话的函数」。

Agent 应用更像：

text
用户
 ↓
任务
 ↓
Agent
 ├── Context
 ├── Tool
 ├── Skill
 ├── Memory / State
 └── Result Validation
       ↓
    多轮执行
       ↓
     最终结果

对我来说，Agent 的核心不是「让模型多想几步」，而是让模型参与一个可执行的任务闭环：拿到上下文、决定要不要调工具、根据结果继续判断，最后交给程序或人验证。

少了闭环，它只是聊天；有了闭环，才谈得上应用。闭环里真正值钱的，往往不是模型本身，而是编排、状态、工具契约和验证——这些东西，和我以前写业务中台时操心的是同一类问题。

2. 第一步：先判断这个需求到底需不需要 Agent ​

不是所有 AI 功能都该做成 Agent。我会先过这张表：

text
固定规则
→ 普通程序

固定流程 + AI 能力
→ AI + Workflow

需要动态决定下一步
+ 需要调用工具
+ 任务存在不确定性
→ Agent

高风险业务
→ Agent + Workflow + 人工确认

几个我会用来自测的例子：

  • 「根据工单描述生成摘要」→ 普通 AI 调用就够。
  • 「工单进来先分类，再按固定规则分派」→ Workflow + 一次模型分类。
  • 「帮我查一下这台设备今天为什么异常停机，并给出建议」→ 更接近 Agent：要查状态、报警、维修记录，路径不固定。
  • 「根据分析结果直接改设备参数」→ 就算用 Agent，也必须人工确认，不能全自动。

我会先问：这件事是不是必须「边跑边决定下一步」？如果答案是否，就不要硬上 Agent。很多项目失败，不是模型太弱，是一开始就选错了形态。选型错了，后面 Prompt 写得再漂亮也救不回来。

3. 第二步：拆任务，而不是先写 Prompt ​

很多人一上来就调 Prompt。我更习惯先把任务拆开，写成一张很土的清单：

  • 输入是什么：用户原话？工单号？设备号？时间范围？缺什么必须追问？
  • 最终目标是什么：一份分析报告？一条建议？还是一次可执行操作？
  • 中间要做什么：查哪些数据、比哪些规则、写哪些中间结论
  • 哪些步骤由程序完成：查询、权限校验、写库、发通知
  • 哪些步骤交给模型：理解问题、选择下一步、解释结果、组织建议
  • 哪些步骤必须人工确认：改数据、触发生产动作、对外发送

拆完之后，Prompt 只是其中一环。没拆清楚就写 Prompt，后面只会在「模型不听话」里打转。

我还会刻意标出「成功标准」：怎样叫完成？怎样叫失败？怎样叫需要人介入？没有成功标准的 Agent，最后只能用「感觉还行」验收——那在企业系统里站不住。业务方要的是可验收，不是可演示。

4. Context 怎么设计 ​

Context 不是「把能找到的信息全塞给模型」。我会拆成几类：

text
System Context     — 角色、边界、禁止事项
业务 Context       — 领域规则、字段含义、业务约束
用户 Context       — 谁在问、权限范围
任务 Context       — 当前目标、已完成步骤、待办
历史 Context       — 必要的会话摘要，不是全文粘贴
工具结果           — Tool 返回的结构化数据

原则很简单：

Context 越多不一定越好，关键是当前任务真正需要什么。

企业系统里信息量很大。MES 里一台设备相关的状态、报警、工单、质检、班次，全塞进去，模型既贵又乱。我会按任务裁剪：异常分析就给异常相关；不问库存就不塞库存。

长期信息（角色设定、业务规则）和当前任务信息要分开管理。历史对话过长时，先摘要再带入，而不是无限追加。工具结果尽量结构化进 Context，少把「一大段自然语言日志」原样塞回去——那会污染后续判断。

做企业系统的人其实早就懂：接口返回什么、给下游用什么，本来就该裁剪。Agent 的 Context 设计，本质上还是这件事。

5. Tool 怎么设计 ​

从工程角度看，Tool 就是 Agent 可以调用的能力接口。模型负责判断和选择；Tool 负责确定性工作。

我会按写 Java API 的标准来设计 Tool：

  • 参数明确：设备号、时间范围、工单 ID，类型清楚
  • 返回结构化：JSON / 明确字段，而不是一大段自然语言
  • 考虑失败：超时、无数据、权限不足，要有错误码和说明
  • 有权限边界：能查什么、能不能写、谁能调
  • 幂等与副作用说清楚：多次调用会不会重复建单

结合业务系统，常见 Tool 可能是：

text
queryOrder()
queryEquipment()
queryQualityData()
createWorkOrder()
sendNotification()

注意：createWorkOrder() 这类写操作，我会默认挂在「需人工确认」之后，而不是让 Agent 直接连库执行。读和写分开展示给模型，也能降低「顺手改掉」的概率。

Tool 设计得像烂接口，Agent 就会像烂调用方：参数乱填、结果看不懂、失败了还假装成功。很多「模型不行」，其实是 Tool 不行。如果你不愿意把某个能力做成干净的 Service 接口，就先别把它挂给 Agent。

6. Skill 和 Tool 怎么区分 ​

我不纠结名词，只按工程用法分：

text
Tool  = Agent 可以调用的单项能力
Skill = 为完成某类任务总结出来的方法 / 能力组合

例如：

text
Tool：查询 MES 设备状态
Tool：查询报警记录
Tool：查询维修工单

Skill：设备异常分析
  = 知道先查什么、后查什么、怎么组织结论、什么时候该停下来问人

Skill 可以是 Prompt 模板 + 工具编排约定 + 输出格式约束。它不是又一个模型，而是「做这类事时的工作方法」。同一套 Tool，换不同 Skill，就能服务异常分析、点检辅助、知识问答等不同任务，而不必每次从零设计。

对我这种从业务系统过来的人，Skill 更像「领域专家的操作手册」，Tool 更像「系统暴露的 API」。手册可以改，API 要稳。

7. Agent 执行过程 ​

一个我会采用的简化流程：

text
用户提出任务
 ↓
Agent 判断任务类型与目标
 ↓
获取必要 Context
 ↓
决定是否调用 Tool
 ↓
获得 Tool 结果（结构化）
 ↓
继续判断：够不够？还要查什么？
 ↓
结果验证（程序 / 规则 / 必要时人工）
 ↓
返回结果，或请求人工确认

关键点有两个：

  1. 每一步都要能停。不是为了跑满 N 步而跑。信息不足就问用户，比瞎猜强。
  2. 验证在返回之前。模型说「已完成」不算完成。

编排层我会记下：当前步、已用 Tool、中间结论、剩余步数。没有状态的多轮执行，很容易变成无头苍蝇，也很难复盘。出了问题你得能回答：卡在哪一步、调了什么、返回了什么。

8. 结果验证 ​

这是落地时最容易被忽略的一环。

不能：

text
模型说成功 = 系统真的成功

应该：

text
模型输出
 ↓
程序验证（字段、状态码、是否真的写库）
 ↓
业务规则验证（权限、状态机、时间窗口）
 ↓
必要时人工确认
 ↓
最终结果

例如模型说「已创建维修工单」，程序就该查工单表或接口返回：有没有单号、状态对不对。没有单号，就当失败，而不是把模型的自信话术展示给用户。

分析类任务也要验证「依据是否来自 Tool 结果」：结论里引用的报警码、时间、设备号，最好能回溯到某次调用。对不上的断言，直接降级为「不确定」或要求补充查询。企业用户对「说得像真的」很敏感，一次无依据的断言比十次「我不确定」更伤信任。

9. 如果放到真实业务系统里 ​

结合我熟悉的领域，我会这样看：

MES / 工业现场
优先做低风险分析：异常解释、点检辅助、工单知识问答。查询和分析可以交给 Agent；改参数、启停设备必须权限 + 人工确认。这是设计判断，不是「我已经上过线的 AI MES」。

ERP / CRM / OA
适合：跨模块信息汇总、申请材料整理、异常单据解释。写库、过审、资金相关操作仍走原有业务代码和审批流。Agent 更像「会查系统的助理」，不是「替代业务服务的执行器」。

内容生产
我在做 AI 漫剧相关平台时，更倾向把「检查设定冲突 → 改建议 → 再生成 → 再检查」做成可编排任务，而不是一次 Prompt 出完整剧本。这更接近 Agent 的使用方式，也更容易验证。这条链路上我有实际在推的产品工作，会把它和 MES 上的设计判断分开说。

我会明确区分：已经实践过的（内容链路里的检查 / 生成闭环）、正在推进的、以及还停留在设计判断上的（MES Agent）。不把设计写成交付报告。

10. 一个我会采用的最小 Agent 架构 ​

text
业务系统
   ↓
Agent Orchestrator
   ├── Context
   ├── Model
   ├── Tool
   ├── Skill
   ├── State
   └── Validator
          ↓
       人工确认（高风险动作）

Orchestrator 可以是你自己的服务（Java / Node 都行），职责是：控步数、管状态、调模型、调 Tool、跑验证、记日志。模型只是其中一块，不是整栋楼。

State 很重要：当前任务走到哪一步、已经调过哪些 Tool、中间结论是什么。Validator 不一定复杂：字段校验、权限校验、关键动作二次确认，往往就够挡住大半事故。

日志至少要能回答：这次任务调了谁、入参出参是什么、哪一步失败、最终有没有过人审。没有观测，Agent 出问题只能靠猜——这在传统后端里不可接受，在 Agent 里同样不可接受。

11. 如果重新做，我会怎么做 ​

个人原则就这几条：

  • 小任务开始：先做一个能验证的窄场景，而不是「全能车间助手」
  • 少 Tool：先 3～5 个高质量接口，不要一口气挂二十个
  • 少 Context：只给当前任务需要的，长期规则与任务上下文分开
  • 强验证：模型输出必须经过程序或人
  • 保留人工兜底：尤其是写操作和生产相关动作
  • 先解决真实业务问题：不为了 Agent 而 Agent
  • 日志要能复盘：每一步调用、入参、出参、耗时、是否通过验证

Agent 应用开发，对我来说不是「把聊天框变聪明」，而是把不确定的模型能力，嵌进一套确定性的工程系统里。能做到这一步，才算从 Demo 走向落地。