跳到主要内容

一个小功能为什么不值得上 Agent

· 阅读需 6 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-06-13 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队在接入大模型之后，都会很快进入一个误区：只要某个功能里有“判断”“调用工具”“多轮交互”这些词，就想把它包装成 Agent。看起来好像更先进，也更符合行业叙事。

但真落到工程里，很多小功能的问题恰恰在于它们太小了，小到根本不值得引入 Agent 这一整套复杂度。

我后来越来越明确的一条原则是：能用一次结构化调用解决的问题，不要先升级成带规划、带循环、带状态恢复的 Agent 任务。

这不是保守，而是成本意识。因为对一个小功能来说，Agent 带来的往往不是“更强能力”，而是额外的系统负担：

  • 更多运行时状态
  • 更多日志和追踪字段
  • 更多失败路径
  • 更多权限边界
  • 更多测试和回归成本

先把“小功能”说清楚​

我这里说的小功能，不是指“业务价值小”，而是指它的执行形态足够明确，通常有这几个特点：

  • 输入边界清楚
  • 输出格式明确
  • 上下文可以一次性准备好
  • 不需要在执行过程中反复探索外部世界
  • 失败后可以直接重试或降级

比如下面这些，通常都属于“小功能”：

  • 给一段文章生成 3 个备选标题
  • 把客服对话分类到固定标签
  • 把日志文本提炼成结构化错误摘要
  • 根据规则检查一篇内容是否适合进入待审队列
  • 给一段代码生成单元测试样板

这些事情当然可以硬套成 Agent，但绝大多数时候没必要。

一个真实分水岭：它到底是在“转换”，还是在“探索”​

我现在会先把任务分成三类：

1. 转换型任务​

输入给定，输出格式给定，中间不需要主动探索。

例如：

  • 文本摘要
  • 标题改写
  • 分类打标
  • JSON 抽取

这类任务最适合用结构化输出或函数式封装来做。

2. 判定型任务​

需要模型做判断，但判断空间依然被业务约束住了。

例如：

  • 是否疑似广告内容
  • 是否需要人工复核
  • 是否命中风控规则的高风险档位

这类任务本质上还是单步决策，不需要 Agent 自己规划后续动作。

3. 探索型任务​

只有到这一类，我才会认真考虑 Agent。它通常意味着：

  • 任务目标比较抽象
  • 需要动态决定下一步
  • 需要在工具之间来回切换
  • 需要处理中途失败和状态恢复

例如“根据用户目标先查资料、再生成方案、再调用系统执行、再根据执行结果继续调整”，这才像真正的 Agent 场景。

所以判断边界的关键不是“有没有用到模型”，而是：任务是否要求系统在执行过程中主动探索。

用一次结构化调用能做完的事，别先上循环​

前阵子我在梳理一个内容后台的小功能：输入是一篇草稿，系统需要输出三件事：

  • 是否建议发布
  • 风险等级
  • 最多 3 条审核理由

团队里最开始有人提议做成 Agent：

  1. 先分析草稿
  2. 再调用规则工具
  3. 如果命中敏感项就继续追问
  4. 最后再给审核结论

听起来很完整，但我把需求拆开后发现，这其实就是一个很标准的单步判定任务。真正需要的不是 Agent，而是一个约束严格的结构化输出。

const ReviewDecision = {
  shouldPublish: 'boolean',
  riskLevel: ['low', 'medium', 'high'],
  reasons: 'string[]<=3',
}

const result = await runStructuredTask({
  model: 'fast-model',
  instruction: '根据给定草稿和规则，输出审核建议。',
  input: {
    draft,
    policySnapshot,
  },
  schema: ReviewDecision,
})

这一版的好处非常直接：

  • 没有规划循环
  • 没有额外工具状态
  • 没有多步 trace 要看
  • 失败时直接按请求重试
  • 线上统计也更简单

后来这类请求每天几千次，真正稳定运行靠的不是“更像 Agent”，而是“更像一个受约束的服务节点”。

Agent 会额外引入什么成本​

很多人低估了这一点，以为 Agent 只是“多写一点 prompt”。其实不是。只要你让系统开始自我规划和多步执行，就相当于引入了一层新的运行时。

1. 你需要控制循环预算​

它会执行几步，最多试几次，什么时候该停，这些都要配。

2. 你需要控制工具权限​

小功能一旦挂上 Agent，模型就可能拿到本来不该拿的工具能力。

3. 你需要保存中间状态​

只要它不是一步结束，就会有：

  • 当前步数
  • 当前计划
  • 上一步工具结果
  • 是否需要恢复

4. 你需要解释失败原因​

用户不会接受一句“Agent 执行失败”。你最后还是得把错误翻译成：

  • 模型判断不确定
  • 工具超时
  • 权限不足
  • 上下文缺失

这已经不是一个“小功能”的运营成本了。

我现在用 5 个问题做判断​

只要有人提议“这里上 Agent 吧”，我会先问下面 5 个问题：

  1. 输入能不能在请求开始前一次性准备完整？
  2. 输出能不能定义成明确 schema？
  3. 执行过程是否真的需要动态决定下一步？
  4. 失败后是简单重试，还是需要恢复中间状态？
  5. 工具调用是否超过一个，而且顺序是否会变化？

如果前两个答案是“能”，后面三个答案大多是“否”，那我基本不会上 Agent。

一个更现实的团队建议​

很多团队真正缺的不是 Agent，而是这三层能力：

  • 结构化输出
  • 工具调用幂等
  • 请求级观测和评测

这三层没补好，贸然上 Agent，最后通常只会把本来简单的问题包装得更难排查。

相反，如果这三层已经成熟，那么以后真的遇到探索型任务时，你再往上加 Agent，成本会低很多。因为那时你不是在空地上搭楼，而是在已有工程地基上加一层控制逻辑。

总结​

一个小功能为什么不值得上 Agent？因为很多时候它缺的不是“自主性”，而是“约束性”。

对小任务来说，最宝贵的不是让系统看起来更聪明，而是让系统更可控、更可测、更可回滚。能用一次结构化调用解决的事，就不要先把它做成一套带计划、带状态、带恢复的复杂执行系统。