📘 每日一读｜什么是 Agent？

一句话先给结论：
Agent 不是“更聪明的模型”，而是“会自己拆任务、调工具、跑流程的系统”。
👉 把“流程控制权”从工程师，部分或全部交给 LLM。

如果说 LLM 是「大脑」，
那 Agent = 大脑 + 手脚 + 记忆 + 规则 + 调度器。

一、为什么会出现 Agent？（背景）
传统 LLM 有三个硬伤：
❌ 一次性回答：只能“一问一答” ❌ 不会用工具：不知道什么时候查数据库、搜网页
❌ 不具备持续目标：不会为了一个长期目标反复尝试

现实世界的任务却是这样的：

• 查资料 → 对比 → 决策 → 执行 → 失败 → 再来一次
• 多步、有状态、需要外部系统配合
  👉 Agent 正是为了解决「复杂任务自动完成」而诞生的。

二、Agent 到底是什么？（标准定义）
从工程角度，一个 Agent 至少包含 5 个模块：

1️⃣ Planner（规划器）	- 把用户目标拆成 多个子任务 - 决定先干什么、后干什么 例子： > “帮我分析一个股票” > → 查财报 → 查行业 → 对比同行 → 生成结论
2️⃣ Executor（执行器）	- 真正去 调用工具 - 如：搜索、数据库、代码、接口、RPC
3️⃣ Memory（记忆）	- 短期记忆：当前任务上下文 - 长期记忆：历史偏好、知识 - 工作记忆：中间结果（草稿、候选集） 📌 没有 Memory，就不可能有真正的 Agent。
4️⃣ Tool Interface（工具接口）	Agent 和现实世界的桥梁 - Search API - DB / KV / Redis - 内部服务（如 WXG 的搜索链路） - Code Interpreter 👉 这一步 90% 是后端工程工作。
5️⃣ Controller / Policy（控制器）	- 控制什么时候继续 - 什么时候停止 - 失败要不要重试 很多 Agent 本质是 状态机 + LLM 决策。

1.Workflow和Agent的区别

为什么 2025 年大厂极度谨慎 Agent？🧯	> 2025 年生产系统 = Workflow 为主，Agent 为辅
1. 不可预测 2. 成本失控（token / 工具） 3. 错误放大（自动执行） 4. 安全与权限问题 4. 调试极其困难
✅ 正确姿势
> Workflow 打底，Agent 解决长尾	80% 确定性流程 → Workflow 20% 不可穷举问题 → Agent
**结论：**只要“问题不可完全穷举、要跨多系统查证、并且需要在对话中澄清/协商/决策”，就更应该用 Agent 框架，而不是纯 Workflow。

🧩 ToC 智能客服场景：Workflow vs Agent 逻辑步骤对比表
用户原始诉求：

“我 8 月 1 号下的单今天还没到，收件地址要换，而且我被重复扣费了。”

Workflow（无论是 Dify 的可视化编排，还是 LangGraph 的状态机）非常适合步骤确定 + 条件有限的流程，比如：
1.查询订单 → 格式化答复 2.退货→生成标签→发通知 3.FAQ 检索→返回片段
一旦进入长尾问题，Workflow 就会遇到“分支爆炸”：
例： 同一条“包裹没到”诉求，可能要综合 ①承运商状态 ②发货 SLA ③节假日政策 ④地址异常 ⑤是否会员 ⑥是否已报缺货 ⑦是否已部分签收 ⑧是否叠加优惠券/补发 等。
如果你用固定分支描述： 假设有 5 个意图 × 6 种物流状态 × 3 种用户等级 × 3 个政策时段（平日/大促/假期） × 3 种地理区域，共5×6×3×3×3=810 条潜在路径。
这还没算异常（报损、拒收、欺诈信号）与“对话澄清”的分支。维护成本和上线速度都会被拖垮。此外，Workflow 对 对话中的“澄清—再决策—再行动 并不天然友好，需要把每一步提问、回答、重试都画成节点，复杂而脆弱。

**Agent **场景：用户说“我 8 月 1 号下的单今天还没到，收件地址其实要换，而且我被重复扣费了。”
以 AutoGen/CrewAI 这类 Agent 框架为例，它们把“在对话里动态规划与调用工具”作为第一性能力：
1.意图识别 + 澄清 ● Planner Agent：拆出多意图（物流异常、改址、计费异常），先问关键澄清（订单号/新地址/扣费凭证）。
2.跨系统取证 ● OMS/物流工具：查轨迹与 SLA； 计费/支付工具：核对重复扣款交易； ● CRM：看是否 VIP、是否有历史补偿记录。
3.政策推理与合规 ● Policy/Critic Agent：套用“假期延误 + VIP + 改址”的组合条款，评估可给的补偿区间、是否可免费改址、是否触发风控人工复核。
4.方案生成与协商 ● 提出“改址 + 走加急补发 / 或原包裹拦截 + 退款差额 + 账单冲正”的可行方案，并在对话中按用户反馈实时调整。
5.执行与闭环 ● 调用工单/票据工具，落账/发券/改单/寄件，写入 CRM 备注； ● 生成总结，告知时限与跟踪号； ● 若任一步失败，自动选择备选策略或升级人工。
这些动作里，很多步骤**无法事先“画”成固定分支，需要在对话上下文里做决策、需要跨工具动态组合、需要“问一句 → 查一下 → 再决定”，**这正是 Agent 的强项。

2.Agent框架选择

1️⃣ AutoGPT —— 历史意义 > 工程价值	Github 17.8w Star > Agent 思想的“启蒙运动” - ✅ 自主拆解 ❌ 几乎不可控❌ 成本不可预测❌ 不适合生产 📌 结论：2025 年不建议新项目使用
2️⃣ LangGraph —— 工程师最安全的 Agent 框架 ⭐⭐⭐⭐⭐	Github 13.1w Star > “带状态机的 Agent 编排框架” 你以为它是 Agent， 其实它是： > Workflow + Agent 节点 + 人工可介入 状态可回放 可中断、可续跑 可人工审批 会“发疯” 📌 搜索 / RAG / 企业 Agent 首选
3️⃣ Dify —— 产品化 Agent / Workflow 平台 🧱	> 低代码 LLM 应用平台，不是 Agent 核心引擎 - 适合：ToB / ToC 快速交付标准流程 - 不适合：高自治 高复杂决策
4️⃣ CrewAI —— 多角色协作的“概念友好型”Agent	角色抽象友好，但工程深度有限 - 优点： - 多 Agent 分工直观 - 局限： - 定制能力有限 深度业务不够 📌 适合：Demo、研究、轻量协作
5️⃣ AutoGen（微软）—— 最接近“工程 Agent”的多 Agent 框架 ⚙️	> 事件驱动 + 多 Agent 对话系统 - 多 Agent 天然支持 人类可插入 可分布式 📌 真实使用情况： > 工程能力强，但上手成本高， > 多见于研究型或平台型团队。

四、Agent 在搜索里的真实作用（重点）

Agent = 搜索引擎的「智能编排层」
在搜索链路中，Agent 常见位置：

User Query
   ↓
Agent（理解意图 + 拆任务）
   ↓
多路 Search / Retrieval
   ↓
结果聚合 & 决策

举例：复杂搜索 Query

“帮我找北京租房，预算 5k，通勤 30 分钟，有地铁”
Agent 会做什么？

1. 解析约束条件
2. 多次查询（区域 / 地铁 / 价格）
3. 动态过滤
4. 排序 + 总结
   👉 这是“搜索增强决策”，不是简单检索。

五、为什么 Agent 是「工程主导」？
很多人担心：

“Agent 都是算法，我们后端是不是要凉了？”
恰恰相反。

Agent 里，工程占比极高：

• 任务状态管理、并发 & 超时控制、工具可靠性、幂等、回滚、日志 & 可观测性、安全、权限、风控
  📌 在大厂：

Agent 的失败，80% 是工程问题，不是模型问题。

六、Agent 的真实难点（不是 Demo）
⚠️ 真正难的不是“跑起来”，而是：

1. 长任务稳定性
2. 错误恢复
3. 工具不可用
4. 幻觉与错误决策
5. 成本控制
6. 安全与权限
   所以你看到的大厂 Agent：

• 都是 强约束
• 都是 半自动
• 都有 兜底规则