7.5
深览指数
科技虎嗅·叶小钗··AI 生成
这届Agent，全是草台班子：到底什么Agent 在产生价值？
文章直指当前Agent落地热潮中存在大量泡沫和认知错位。核心结论是：不存在通用Agent，真正产生价值的Agent专注于解决「确定性流程中的非确定性应对」，例如客服、代码审查、企业流程自动化等特定场景。作者将Agent技术选型分为三类场景，并强调其本质是用运行时模型决策（更高成本）换取开发维护成本下降。适合正在思考AI落地选型、需要与老板/客户对齐预期、或对Agent架构现实性有怀疑的技术负责人和AI产品经理阅读。原文 ↗
核心观点
- ▍当前跑出来的Agent不解决通用问题，而是专注于特定场景下的连续性工作，如Coding Agent、客服Agent、企业流程Agent等，核心是利用AI泛化能力解决确定性流程中的非确定性应对。
- ▍Agent并未降低系统复杂度，而是将显式的代码复杂度（if-else分支）转移为隐式的数据与Prompt复杂度（ReAct循环、Tools描述、Few-shot示例），且代码BUG是确定的，Prompt BUG是随机的。
- 01作者通过一个真实案例说明：某企业做AI客服错误选择了Agent架构（文中提及'OpenClaw'，应为'OpenAI Agent/Function Calling'），导致结果不稳定、慢、成本高，根本原因是架构选型错误——客服场景用API+RAG可能更优。
- 02文章以群昵称格式统一为例，说明传统规则引擎和正则表达式无法应对用户输入的千奇百怪，这是大模型泛化能力最核心的应用场景。
- 03作者阐述了Workflow与Agent的关系：Workflow负责确定性主干（如退款已发货/未发货的分支），Agent负责不确定性局部（如用户混合表达退款、物流、赔偿等复杂意图时的意图识别与步骤规划）。
- 04文章指出Agent架构的核心缺陷：多轮推理+多次工具调用带来了更高的延迟和Token成本，且需要构建复杂的可观测性日志系统来调试运行时错误。
- 05作者提出了需求翻译策略：老板/客户要的往往不是Agent本身，而是降本提效、少出错、看起来先进，技术负责人需要将需求重新翻译为三类工程问题：提效已知任务（API+RAG）、替代人工操作流（先梳理SOP）、高价值专业决策（Agent）。
反方 / 局限
- — 作者承认Agent架构带来的调试难、观测难问题，以及由于架构不稳定性、效率低、成本高带来的新工程维护复杂度，这些都需要更多工程手段去解决。
- — 文章隐含一个张力：虽然Agent被认为是更优范式，但作者结尾提醒'好坏大家自己下去感受'，暗示在实际生产环境中，Agent的随机性和成本可能并不总是优于传统Workflow。
14 分钟 · 4 卡片 · 11 资料
读原文 →