#non-ai-agents

这个 Non-AI agents 和它下面的 Human-in-the-loop，其实是 Agent 设计里非常“工程化”、也非常“现实”的一部分。

因为很多人一看到 Agent，就会默认：

Agent = 一定是大模型 = 一定是 AI

但这部分文档想告诉你的是：

在一个 Agent 系统里，不一定所有“参与者”都必须是 LLM。

有些节点、角色、执行者，完全可以不是 AI，而是：

• 普通 Java 代码
• 规则引擎
• 工作流节点
• 外部系统
• 甚至是人工审批 / 人工干预

这就是 Non-AI agents 的核心思想。

---

一、先用一句最通俗的话解释：Non-AI agents 是什么？

你可以先记住这句话：

Non-AI agents = 在 Agent 工作流里，有些“代理角色”并不是大模型，而是普通程序、规则逻辑、系统组件或者人。

也就是说，整个“Agent 系统”不是非得全靠 AI 才成立。

---

二、为什么会有 Non-AI agents 这个概念？

因为真实项目里，很多事情没必要交给 LLM。

甚至有些事情 不应该 交给 LLM。

比如：

• 查数据库
• 判断用户权限
• 调用支付接口
• 扣库存
• 状态流转
• 审批确认
• 风险拦截
• 固定规则判断

这些事情通常：

• 有明确规则
• 要求强确定性
• 不希望模型自由发挥
• 有副作用
• 有安全风险

如果你还强行让 AI 去决定，很容易出问题。

所以文档里提出 Non-AI agents，其实是在提醒你：

Agent 系统里的“智能协作单元”，可以是 AI，也可以不是 AI。

---

三、怎么理解“Non-AI agent”这个词，不要被“agent”误导

这个地方很容易误解。

很多人看到 “agent” 就以为一定是“会推理的大模型代理”。

但在这个语境里，agent 更像一个“执行角色”或“任务节点”。

所以：

• AI agent：由 LLM 驱动，擅长理解、推理、生成
• Non-AI agent：由程序逻辑/规则/人来驱动，擅长确定性处理

你可以把它理解成：

Agent 是工作流里的一个“参与者”，不一定是 AI。

---

四、Non-AI agents 是干什么的？

核心作用

它的核心作用是：

让 Agent 系统不必“全 AI 化”，而是把适合 AI 的部分交给 AI，把适合程序/规则/人工的部分交给非 AI。

这其实是非常健康、非常实战的设计思路。

---

五、它能解决什么问题？

---

1）解决“AI 不适合做所有事情”的问题

LLM 很擅长：

• 理解自然语言
• 总结
• 推理
• 生成
• 提建议

但它不擅长或者不适合做：

• 严格规则判断
• 精准数学计算
• 强一致状态更新
• 权限校验
• 高风险动作确认

所以系统里就需要有 Non-AI agent 来承担这些部分。

---

2）提高稳定性和可控性

AI 有不确定性，但程序规则更确定。

比如：

• 是否允许退款
• 是否有权限查订单
• 是否满足审批条件

这些用 Java 规则判断更稳。

---

3）降低成本

不是所有环节都值得调用一次大模型。

有些事情 3 行 if/else 就解决了，没必要走 AI。

---

4）满足合规与安全要求

比如：

• 删除数据前必须人工确认
• 风险订单必须人工复核
• 金额超过阈值必须审批

这些天然适合 Human-in-the-loop 或 Non-AI 规则节点。

---

六、Spring Boot 开发者怎么理解 Non-AI agents？

这个其实特别好理解。

你可以把 Non-AI agents 直接理解成：

• 一个普通 @Service
• 一个规则处理器
• 一个审批节点
• 一个策略类
• 一个状态机节点
• 一个外部系统适配器

它们虽然不是 AI，但在 workflow / agent system 里扮演了“行动者”的角色。

---

比如这些都可以看成 Non-AI agent：

• PermissionCheckAgent
• OrderValidationAgent
• RiskControlAgent
• PaymentExecutionAgent
• ManualApprovalAgent
• RuleBasedRouterAgent

这些名字里虽然有 Agent，但本质可能只是普通 Java 类。

---

七、一个很通俗的例子：电商客服系统

假设你做一个智能客服系统。

用户说：

帮我退款这个订单。

整个流程可能有这些节点：

---

AI Agent 负责

• 理解用户意图
• 提取订单号
• 判断用户是在申请退款还是咨询退款规则
• 生成最终回复文案

---

Non-AI Agent 负责

• 校验订单是否存在
• 判断是否满足退款规则
• 检查用户权限
• 调用退款接口
• 写审计日志

---

你会发现：

这才是一个真实可落地的系统。
AI 负责“理解和决策辅助”，Non-AI 负责“确定性执行和安全控制”。

---

八、它通常有哪些典型形态？

Non-AI agents 通常会以这些形式出现：

---

1. Rule-based agent（规则型）

通过固定规则处理。

比如：

• 订单金额 > 1000 必须人工审批
• 已签收超过 7 天不允许退款

这种最适合 Java 代码写死。

---

2. Deterministic service agent（确定性服务型）

直接调用系统能力。

比如：

• 查询数据库
• 调支付接口
• 发短信
• 创建工单

其实就是普通 Service。

---

3. Workflow control agent（流程控制型）

控制分支、状态、权限。

比如：

• 决定进入哪个后续流程
• 如果缺少参数则终止
• 如果高风险则转人工

---

4. Human agent（人工节点）

这就是下面的 Human-in-the-loop。

比如：

• 审批
• 复核
• 人工确认
• 人工补充信息

---

九、Human-in-the-loop 是什么？

这个非常重要。

---

1）最通俗的理解

Human-in-the-loop 的意思是：

在 Agent 工作流中，把“人”作为一个关键环节放进来。

也就是说：

• 不是所有事情都让 AI 自动做完
• 某些阶段要让人工介入、确认、审核、补充或接管

---

2）为什么要有人介入？

因为真实业务里，总会有一些情况：

• AI 没把握
• 风险太高
• 涉及资金/权限/隐私
• 规则复杂
• 用户情绪问题需要人工安抚
• 法务/合规要求必须人工确认

这时候就不能让 Agent 自己一路跑到底。

所以 Human-in-the-loop 的核心就是：

让系统在需要时，把决策权或执行权交还给人。

---

十、Human-in-the-loop 能干什么？

它通常有这几类作用：

---

1. 人工审批

比如：

• 超过 5000 元退款，必须客服主管审核
• 删除客户数据，必须管理员确认

---

2. 人工兜底

当 AI 不确定时，交给人。

例如：

• 置信度太低
• 无法识别用户意图
• 多次 tool 调用失败

---

3. 人工补充信息

例如：

• AI 无法确认订单号
• 需要客服补充上下文
• 需要用户重新确认需求

---

4. 人工纠错

比如：

• AI 给的方案不靠谱
• 工具调用建议不合理
• 结果需要人工修订后才能发送

---

5. 人工接管对话

特别是在客服系统中很常见。

比如：

• 用户投诉升级
• 用户情绪激动
• AI 连续两次回答失败

这时候直接转人工客服。

---

十一、一个实际流程例子：退款申请

我们用你熟悉的 Spring Boot 电商场景讲。

---

用户输入

我要退款订单 A10086

---

可能流程

Step1: AI Agent 理解用户意图 -> 退款申请
Step2: Non-AI Agent 校验订单是否存在
Step3: Non-AI Agent 校验是否满足退款规则
Step4:
   - 如果金额小、规则明确 -> 系统自动退款
   - 如果金额大、存在争议 -> Human-in-the-loop，人工审批
Step5: AI Agent 生成回复给用户

---

这里谁是谁？

• AI Agent：理解用户意图、生成自然语言回复
• Non-AI Agent：规则校验、执行退款动作
• Human-in-the-loop：高风险时人工审批

这就是一个很典型的混合式 Agent 系统。

---

十二、Spring Boot 里怎么理解 Human-in-the-loop？

你可以把它理解成一个“人工审批节点”或者“人工任务节点”。

就像工作流引擎里的：

• 待审批
• 待复核
• 待人工处理

例如：

if (refundAmount > 5000) {
    manualReviewService.createTask(orderId, userId);
    return "退款申请已提交，等待人工审核";
}

这个 manualReviewService 本质上就可以看作是 Human-in-the-loop 的落地实现。

---

十三、Non-AI agents 和 Human-in-the-loop 的关系

它们的关系可以这样理解：

---

Non-AI agents

范围更大，指的是：

所有不是 LLM 的 Agent 节点。

包括：

• 规则节点
• Service 节点
• 权限校验节点
• 状态机节点
• 人工节点

---

Human-in-the-loop

是 Non-AI agents 的一个特殊子类：

由“人”来作为节点参与系统。

所以 Human-in-the-loop 可以理解为：

Non-AI agent 中最特殊、最重要的一类。

---

十四、为什么这部分对企业项目特别重要？

因为企业项目不能“唯 AI 论”。

真正能落地的系统，通常都不是：

全部让 AI 自动做完

而是：

AI + 规则 + 服务 + 人工 + 监控 + 兜底

共同组成一个系统。

所以 Non-AI agents 这部分文档，是在提醒开发者：

别把 Agent 系统理解成“只有模型在干活”，实际可用的系统一定是混合型的。

---

十五、你作为 Spring Boot 开发者最应该抓住什么？

我建议你重点抓住下面这几个点。

---

1. Agent 不等于 LLM

这是最重要的认知。

在系统设计里，Agent 更像“任务参与者”。

---

2. 非 AI 节点往往更适合做关键业务控制

例如：

• 权限
• 风控
• 状态变更
• 副作用操作
• 数据写入

这些尽量别完全交给 LLM。

---

3. 人工介入不是“系统不智能”，而是“系统更现实”

Human-in-the-loop 不是降级，而是生产级系统必须有的能力。

---

4. 最好的系统通常是混合系统

最稳的落地方式通常是：

• AI 做理解、分类、总结、建议
• Non-AI 做规则、执行、控制
• Human 做审批、复核、兜底

---

十六、你可以怎么记住它？

我给你一个非常好记的版本：

• AI Agent：擅长“理解和思考”
• Non-AI Agent：擅长“规则和执行”
• Human-in-the-loop：擅长“高风险决策和兜底”

---

十七、最后一句话总总结

Non-AI agents 讲的是：在 Agent 系统中，不是所有节点都必须由 AI 驱动，很多任务更适合由规则代码、系统服务或人工来承担；而 Human-in-the-loop 则是把“人”明确纳入工作流中，用于审批、兜底、纠错和高风险场景控制。

---

如果你愿意，我下一步可以继续帮你做两个非常适合你学习的内容：

方案 A：偏理解

我可以把 AI Agent / Non-AI Agent / Human-in-the-loop 三者做一个系统对比表，帮你彻底理清在项目中怎么分工。

方案 B：偏实战

我可以直接用 Spring Boot 电商退款场景，给你画一个完整流程，里面同时包含：

• AI Agent
• Non-AI Agent
• Human-in-the-loop
• Tool
• Workflow

如果你想继续，直接回复我一句：

继续，对比 AI Agent / Non-AI Agent / Human-in-the-loop
或者
继续，用 Spring Boot 退款场景画完整流程