小龙虾 OpenClaw：Agent 价值与边界

• 原文链接：https://mp.weixin.qq.com/s/1UBJXsucthMXZdZcQKKWCA
• 作者：未署名(AI Agent 类技术公众号)
• 发布时间：2026-06

核心结论（一句话）

Agent 没那么玄乎——”把程序员写死在代码里的 if-else，挪到了运行时让模型现挂”；3 大结论：① 不存在通用 Agent(特定场景做深)② 受控的自由(明确边界下的受控智能)③ Agent 价值在于智能(用不稳定性换泛化能力);“老板要 Agent ≠ 真要 Agent”——翻译 3 类真实需求:API+RAG(提效)/ Workflow+SOP(替代人工)/ Agent+受控(高价值决策)。

分类提炼

• 场景:Agent 落地价值判断 / 技术选型决策树 / 需求翻译
• 标签:#主题/Agent价值 #主题/Agent边界 #主题/翻译需求 #主题/Workflow与Agent融合 #主题/受控的自由
• 类型:方法论 + 反面案例 + 翻译模板

知识节点(10 个独立概念)

• 不存在通用 Agent:当前跑出来的 Agent 不解决通用问题,反而更专注特定场景的连续性工作;核心使用其泛化能力解决”确定性流程中的非确定性应对”
• 5 类已落地 Agent:Coding / 客服 / 法律 / 医疗 / 企业流程;都是【高密度、低创意、高容错】脏活累活
• 受控的自由:生产级 Agent 对稳定性要求极高;Agent = 在有明确边界下的受控智能;没解决稳定性和安全性的产品很难上线
• Agent 价值在于智能:智能受追捧源于人的惰性,ReAct 架构被诟病源于不稳定性+高成本;Agent 没降低复杂度,是把显式代码复杂度转移成隐式数据与 Prompt 复杂度
• 代码 BUG 确定 vs Prompt BUG 随机:以前维护 100 个 if-else 痛,现在维护 ReAct 循环+工具描述+Few-shot 同样痛,只是疼法不同
• Workflow + Agent 融合:Workflow 负责确定性主干,Agent 负责不确定性局部——不冲突,是融合
• 翻译 3 类真实需求:① 提效已知任务 → API+RAG 就够;② 替代人工操作流 → 先把 SOP 梳理清楚;③ 高价值专业决策 → 适合 Agent+受控
• 老板要的不是 Agent:大多数老板要的是降本提效、少出错、看起来先进可以吹牛;接到”要 AI”的需求 → 先翻译 3 类再选技术路径
• 业务分支有限 vs 用户表达无限:Agent 出现的本质原因;规则引擎搞不定”我昨天买的那个东西还没收到”这种模糊表达
• Agent 本质 = 生成工作流的工作流:给出一套”将问题编译为可执行计划”的框架;Agent 架构可理解为 Workflow 本身

关联图谱

上游(基于 / 来自)

• ReAct 技术架构 / 规则引擎 vs 大模型 范式之争 / 业务分支有限 vs 用户表达无限的经典矛盾

下游(应用于 / 验证于)

• Seetong AI 助手:按 5 类 Agent 拆分(设备分诊/反馈分诊/远程操作/添加设备/报警处理)
• Seetong 客服 SOP:先梳理清楚 SOP 再选 Agent 还是 Workflow
• Seetong 老板/客户需求翻译:接到”要 AI”的需求 → 先翻译 3 类再选技术路径
• Seetong 高价值决策 Agent:设备异常诊断、性能优化 = 适合 Agent+受控的自由

同级(横向 / 并列)

• [[Leeka-Task-Decomposition-Agentic-Workflow]] - 互补(Leeka 是”怎么拆”,本文是”该不该拆/什么时候选 Agent”)
• [[Addy-Osmani-Loop-Engineering]] - Loop 验证才能解决 Prompt BUG 随机问题
• [[0xCodez-Agent-Harness-14-Steps]] - Harness 14 步法
• [[阿里妹-端到端业务需求专家Agent-4层架构8步流程]] - 业务端 Agent 架构
• [[阿里云开发者-淘宝主播Agent的Harness工程实战]] - 阿里淘宝 Agent 实战
• [[清华沈阳-自进化AI新物种]] - 自进化 AI
• [[Multica-AI-Native-组织-人是最慢的节点]] - AI Native 组织
• [[Harness不是目的-知识才是护城河]] - Harness vs 知识护城河

正文要点(5 条)

1. 真实使用三阶梯:有用户(微量/少量/大量)/ 有活跃度(用两次/多次/频繁依赖)/ 有持续付费(无/低/高)
2. 不存在通用 Agent——当前跑出来的 Agent 都”特定场景里把一类任务做深”;核心使用其”泛化能力解决确定性流程中的非确定性应对”
3. 3 大结论——① 不存在通用 Agent ② 受控的自由(明确边界下的受控智能)③ Agent 价值在于智能(用不稳定性换泛化能力)
4. 代码 BUG 确定 vs Prompt BUG 随机——Agent 没降低复杂度,是把显式代码复杂度转移成隐式数据+Prompt 复杂度
5. 老板要的不是 Agent——大多数老板要的是”降本提效、少出错、看起来先进可以吹牛”;翻译 3 类真实需求

6 个对 Seetong 团队可借鉴动作

1. 老板要 Agent ≠ 真要 Agent:先做”翻译对照”(降本/提效/看起来先进/少出错)
2. Seetong 三类需求分类:① 提效已知(用户登录成功率)→ API+RAG ② 替代人工(客服分诊/反馈分诊)→ 先 SOP ③ 高价值决策(设备异常诊断/性能优化)→ Agent+受控
3. 不存在通用 Agent——按场景拆:5 类(设备分诊/反馈分诊/远程操作/添加设备/报警处理),与 Leeka 一致
4. Workflow 确定性主干 + Agent 局部不确定:客服分诊 = Workflow(已知分类)+ Agent(意图识别);不搞”全 Agent”
5. 业务分支有限 vs 用户表达无限:反馈”七大症状”按”原话分类+意图识别”拆,不枚举表达
6. 代码 BUG 确定 vs Prompt BUG 随机:Seetong AI 助手所有 Agent Skill 必须配 Eval Gate(与 Addy Loop 验证一致)

备注与限制

• 与 [[Leeka-Task-Decomposition-Agentic-Workflow]] 互补:Leeka 关注”怎么拆”,本文关注”该不该拆/什么时候选 Agent”
• 与 [[Addy-Osmani-Loop-Engineering]]:本文提出”代码 BUG 确定 vs Prompt BUG 随机”问题,Addy Loop 验证是部分答案
• 特别发现:作者用”小龙虾 OpenClaw”做反面案例——本机 OpenClaw 是 gateway 平台,不是单一 Agent 用途——有趣双关;Seetong 沟通澄清”OpenClaw 平台 ≠ 直接做 AI 客服 Agent”
• 核心反直觉:Agent 不是取代 Workflow,而是 Workflow 负责确定性主干,Agent 负责不确定性局部——融合而非替代
• 不适用:把 Agent 当”全能助手”;把”老板要 AI”直接当 Agent 需求
• 未展开:翻译 3 类需求的实操模板;5 类 Agent 的 ROI 数字

相关链接

• 原文:https://mp.weixin.qq.com/s/1UBJXsucthMXZdZcQKKWCA
• 同主线 [[Leeka-Task-Decomposition-Agentic-Workflow]] / [[Addy-Osmani-Loop-Engineering]] / [[0xCodez-Agent-Harness-14-Steps]] / [[阿里妹-端到端业务需求专家Agent-4层架构8步流程]] / [[阿里云开发者-淘宝主播Agent的Harness工程实战]] / [[清华沈阳-自进化AI新物种]] / [[Multica-AI-Native-组织-人是最慢的节点]] / [[Harness不是目的-知识才是护城河]]
• 反向参考:[[Harness不是目的-知识才是护城河]]——知识护城河比 Harness 重要;本文”翻译 3 类”也是”业务架构比 Agent 重要”