我做了几年 Java 后端，转过来做 Agent 平台时，第一反应是补模型知识：prompt 怎么写、上下文怎么排、工具怎么调。

这些当然重要。但真正让我加班最多的，不是模型，是状态。

模型只是链路中的一段

一个 Agent 任务，在 Java 后端眼里是这样的：

  • 接收请求，做鉴权、限流、参数校验；
  • 创建任务，落库，返回任务 ID；
  • 异步执行，调模型、调工具；
  • 保存中间结果和最终产物；
  • 更新状态，处理超时、重试、取消；
  • 记录 token、耗时、成功率；
  • 对外提供查询、下载、审计。

模型只占其中一段。剩下的是很传统的后端问题：事务、并发、幂等、补偿、可观测性。

控制面和执行面要分开

我后来把系统分成两层：

  • 控制面：管身份、权限、任务、额度、产物、审计；
  • 执行面：管 Agent 循环、模型调用、工具执行。

控制面要稳，执行面要能扩。两层之间用明确的契约通信：任务 ID、状态、输入、输出、错误码、token 用量。

分开之后，好处很明显：

  • 执行面挂了，控制面还能查任务、退额度；
  • 执行面换实现，控制面不用动；
  • 出问题能定位是“调度没调起来”还是“模型/工具失败”。

状态是最容易低估的东西

Agent 任务不是“一次请求-一次响应”，它可能跑几分钟，可能中途等人工，可能失败重试。

这意味着：

  • 不能把状态只放在内存里；
  • 不能只靠“请求超时”判断任务失败；
  • 不能重试就重新扣一次费；
  • 不能让用户看不到进度。

这些问题，和微服务里的事务、补偿、幂等是一回事。Java 后端的那套东西，在 Agent 场景里不是过时，是刚好用得上。

我现在的学习重点

如果只让我列三个，我会列：

  1. 评测：怎么证明 Agent 变好了，而不是“感觉变好了”；
  2. 权限与安全：工具怎么管、Key 怎么管、Prompt 注入怎么防；
  3. 上下文工程：什么该进上下文、什么该丢、怎么压缩。

框架会变，这三个不太会变。

最后一句

Agent 不是“后端 + 一个大模型接口”。它是一个会跑很久、会调很多外部系统、会失败、会重试的分布式任务系统。

模型决定它聪不聪明，后端决定它靠不靠谱。