这是什么

我们注意到一个反直觉的事实：搜索、OCR、文件解析这些边界清晰的能力，硬包成 Agent（让 AI 自主调用工具完成任务的程序）后，成本、延迟和故障点都会增加 — 多了一次模型推理、一层上下文和不可预测的输出格式。

Agent 的价值在另一侧：理解模糊目标、制定计划、选择工具、解释结果。源文章建议分层：

  • 能力/工具层：搜索、OCR、知识检索、记忆 — 做事
  • Agent Runtime：通用、领域、编排 Agent — 判断
  • Unified Gateway：身份、授权、路由、计费、审计 — 管边界

很多人以为用 MCP（让 Agent 调用外部工具的标准协议）和 Skill（提示模板）接上了就算搭好了 Agent 平台，实际只是「宿主 Agent → Skill → 本地 MCP 进程 → WebSocket → 外部 Agent」一条适配链路，没有真正的流式体验、用户/租户绑定、计费审计，MCP SDK 一升级还可能断。

行业怎么看

支持视角：源文章代表的工程派强调克制 — 不盲目 Agent 化，先把能力、Agent、Workflow（按预设规则执行的步骤）、Platform Governance 分清楚。这与近半年业界从「堆 Agent」转向「Agent 落地」的反思一致。

反对视角一：也有团队认为「边界模糊正是 Agent 的优势」。业务规则频繁变化时，把流程硬拆成 Workflow 反而丧失灵活性；把搜索做成工具，未来需要语义理解时又得重构。两极都有代价，没有标准答案。

反对视角二：源文章推荐的三层架构，对只有 1-2 个 Agent 的小公司是过度工程。现实里很多团队连「把聊天机器人接上知识库」都没做好，就先设计多 Agent 平台 — 这是更常见的失败模式。

对普通人的影响

对企业 IT：评估「上 Agent」前，先问一个更基础的问题 — 这件事到底需不需要 Agent。搜索、文件解析、数据库查询做成 API 通常就够了；合同审核、风险识别这种模糊任务才有必要。买平台前看清：对方卖的是「统一入口」还是「一堆微服务」。

对个人职场：未来 1-2 年，「能设计 Agent/工具/Workflow 分层」会比「会调 API」更值钱。不是所有 AI 工作都需要 Agent 思维，先把确定性的部分用工具解决，把判断留给 Agent，把规则留给 Workflow。

对消费市场：当一家公司说「我们做了 Agent」，多问一句 — 它是真的 Agent，还是 Skill + MCP 包起来的适配器？两者稳定性、扩展性和成本结构完全不同。