Agent 不是聊天框，而是产品能力的编排层

最近在设计一套接入现有产品框架的 Agent 模块，越想越觉得：很多人把 Agent 理解成“一个更聪明的聊天框”，这个方向从一开始就有点偏。

真正有价值的产品型 Agent，不是站在产品旁边陪用户聊天，而是站在 用户目标 和 产品能力 中间，帮用户把一句模糊的人话，翻译成一组可执行、可解释、可追踪的产品动作。

Agent 的本质不是替产品加一个自然语言入口，而是在产品能力之上增加一层目标理解、能力选择、流程编排和执行治理。

这句话是我现在对 Agent 最核心的理解。

先给结论

一、为什么复杂产品天然需要 Agent

复杂产品里，用户经常遇到两个问题。

第一，用户知道自己想要什么，但不知道怎么说清楚。

比如用户说：

帮我把最近异常的客户整理一下。

这里面至少有几个模糊点：

• “最近”是今天、本周，还是最近 30 天？
• “异常”是活跃下降、投诉增加、续费风险，还是指标偏离？
• “客户”是全部客户，还是某个区域、行业、负责人名下的客户？
• “整理一下”是生成列表、导出报表，还是推送给某个人？

换成 Agent 的视角，这句话不是一句命令，而是一组待补全的任务变量：

第二，用户知道目标，但不知道产品里应该用哪些功能实现。

产品功能越多，这个问题越明显。按钮、菜单、筛选器、报表、规则、配置、权限、任务流都在那里，但用户不一定知道什么时候该用哪个。

这不是用户笨，而是复杂产品的正常结果：

产品能力越强
  -> 功能入口越多
    -> 用户认知成本越高
      -> 目标和功能之间出现断层

Agent 要填的就是这个断层。

传统产品是功能导向：

你要自己知道入口在哪里，参数怎么填，流程怎么走。

Agent 化产品是目标导向：

你说目标，系统帮你澄清、拆解、选择能力、执行动作，并解释结果。

这就是它的产品价值。

二、行动型 Agent 和洞察型 Agent

我现在更倾向把产品里的 Agent 分成两类：行动型 Agent 和 洞察型 Agent。

行动型 Agent 主要做产品功能调用。它帮助用户完成创建、配置、查询、筛选、生成、导出、推送、处理等动作。

洞察型 Agent 主要做信息收集和分析。它读取数据、理解指标、发现异常、解释原因、给出建议。

这两类不是完全割裂的。一个成熟 Agent 往往都会经历同一个循环：

理解需求
  -> 补充上下文
    -> 选择工具
      -> 执行或查询
        -> 观察结果
          -> 总结、追问或继续行动

区别只在主目标。

行动型 Agent 的核心是 完成任务。
洞察型 Agent 的核心是 形成判断。

所以如果一句话区分：

行动型 Agent 连接用户目标和产品功能；洞察型 Agent 连接业务数据和管理决策。

这也解释了为什么我会先做行动型 Agent。

行动型 Agent 更容易验证价值。它有没有减少操作步骤、有没有帮用户把事做完、有没有降低配置错误，一看就知道。

洞察型 Agent 更难。尤其是给客户领导使用时，它不只是“查数”，而是要回答：

当前整体情况怎么样？
哪里异常？
风险在哪里？
为什么会这样？
下一步应该关注什么？

这要求系统不只懂数据源，还要懂指标体系、业务语义和证据追溯。

三、行动型 Agent 不能只是 API Router

最容易做出来、也最容易做浅的一种 Agent，是 API router。

流程大概是：

用户说一句话
  -> 模型判断调用哪个接口
    -> 后端执行
      -> 返回结果

这当然有用，但价值有限。因为它只是把按钮换成了自然语言。

真正的行动型 Agent，至少要多做几件事：

1. 判断用户目标是否清晰。
2. 信息不足时主动追问。
3. 知道产品有哪些能力，以及每个能力适合什么场景。
4. 把复杂目标拆成多个步骤。
5. 在高风险动作前请求确认。
6. 调用工具后观察结果，而不是只管发请求。
7. 告诉用户做了什么、为什么这样做、结果是什么。
8. 留下可审计的执行记录。

所以它更像这样：

用户表达
  -> 意图理解
  -> 槽位补全
  -> 能力匹配
  -> 执行计划
  -> 风险判断
  -> 用户确认
  -> 工具调用
  -> 结果解释
  -> 审计记录

这里面最关键的是 能力匹配。

不要把产品后端的一堆接口原样扔给模型。内部 API 往往是面向工程实现的，不是面向用户任务的。Agent 需要的是一层更稳定的“产品能力”。

一个能力可以这样定义：

能力名称：创建客户风险报表
适用场景：用户想查看客户风险、续费风险、活跃异常
输入参数：时间范围、客户范围、指标口径、输出格式
权限等级：需要报表查看权限
风险等级：低风险，只读
执行器：调用报表服务生成
结果解释：返回摘要、下载链接、异常客户列表

这比直接暴露一个 POST /reports/create 更适合 Agent 使用。

Agent 面对的不是接口，而是带语义、边界和风险等级的产品能力。

判断标准：如果一个 Agent 只是把自然语言映射到接口，它只是命令入口；如果它能澄清、规划、确认、执行、解释和审计，它才开始像一个产品型 Agent。

四、可以参考的主流架构范式

这几年行业里 Agent 框架很多，但抽象下来，主流架构大概有五类。

1. 工具调用循环

代表是 OpenAI Agents SDK、Semantic Kernel、Amazon Bedrock Agents。

它们的核心都是：

模型理解输入
  -> 选择工具
    -> 执行工具
      -> 把结果放回上下文
        -> 模型继续判断

这类架构最适合行动型 Agent，因为它天然对应“调用产品功能”。

优势是简单、直接、容易接入现有系统。缺点是如果缺少工作流和风险控制，很容易变成不可控的自动调用器。

2. 图和工作流编排

代表是 LangGraph、Google ADK Graph Workflows、LlamaIndex Workflows、CrewAI Flows、Dify Workflow。

它们强调把执行过程拆成节点、边、状态和事件：

识别意图节点
  -> 补槽节点
  -> 计划节点
  -> 确认节点
  -> 执行节点
  -> 总结节点

我认为这是产品型 Agent 最值得借鉴的方向。

因为真实产品里，不是所有步骤都应该交给模型自由决定。有些流程应该用确定性代码控制，比如权限检查、风险判断、确认弹窗、回滚逻辑、审计写入。

模型负责理解和选择，工作流负责边界和秩序。

3. 多 Agent 协作

代表是 AutoGen、CrewAI、OpenAI handoffs、LangGraph subgraphs。

它们把一个复杂任务拆给多个角色：

Planner Agent：拆任务
Executor Agent：执行工具
Verifier Agent：检查风险和结果
Analyst Agent：分析数据
Reporter Agent：生成报告

多 Agent 适合复杂研究、长任务、洞察分析、代码任务这类场景。

但我不建议一开始就为了“高级”而多 Agent 化。多一个 Agent，就多一份上下文同步、成本、延迟和不确定性。

对当前行动型 Agent 来说，更稳的做法是：

单 Agent 主流程
  + 明确工作流
  + 必要时 handoff 给专门能力

4. 企业托管 Agent 平台

代表是 Amazon Bedrock Agents、Microsoft Foundry Agent Service、Google Vertex AI / ADK。

这类平台把模型、工具、知识库、运行时、权限、监控、部署、版本和审计都纳入平台。

它们给产品架构一个很明确的启发：

Agent 不是一个模型调用函数
Agent 是一套运行时系统

真正上线后，你需要关心：

• 谁调用了 Agent？
• Agent 调用了哪些工具？
• 参数是什么？
• 结果是什么？
• 是否越权？
• 是否经过用户确认？
• 失败能不能恢复？
• 成本和延迟是多少？

这些东西不性感，但决定 Agent 能不能进生产。

5. MCP 和工具协议

MCP 的价值在于标准化 Agent 和外部系统的连接方式。

它想解决的是：

每个模型、每个客户端、每个工具都写一套适配

变成：

工具按统一协议暴露
Agent 按统一协议发现和调用

如果一个产品未来希望自己的能力不仅被内部 Agent 调用，也可能被外部 Agent、IDE、自动化平台调用，那么 MCP 这类协议非常值得关注。

但这里也有一个风险：不要把内部 API 裸露成工具市场。

工具协议解决的是连接问题，不解决产品语义、安全边界和权限治理。真正暴露给 Agent 的，仍然应该是经过设计的产品能力。

五、我更倾向的产品接入架构

如果把这些范式收敛到一个现有产品里，我会选择这个组合：

工具调用循环 + 显式工作流编排 + 产品能力注册中心 + 权限确认 + 可观测日志。

结构大概是：

前端交互层
  -> Agent 编排层
    -> 意图理解
    -> 上下文管理
    -> 工作流状态机
    -> 能力选择
    -> 权限和风险判断
      -> 产品能力注册中心
        -> 报表能力
        -> 配置能力
        -> 查询能力
        -> 导出能力
        -> 通知能力
      -> 产品后端服务
  -> 执行结果、解释、审计日志

这里有几个设计点。

1. 前端不是 Agent 的大脑

前端应该负责输入、展示、确认、进度反馈和结果可视化。

真正的意图理解、权限校验、工具调用、状态保存、审计记录，最好放在后端或独立 Agent orchestration 层。

否则会遇到很多问题：权限不好控、上下文容易泄露、长任务难恢复、执行日志难统一。

2. 能力注册中心比工具列表更重要

模型不应该面对一堆没有业务语义的接口。

能力注册中心至少要描述：

这样 Agent 才能把用户目标映射到产品能力，而不是在 API 海里猜。

一个更接近落地的能力卡片可以长这样：

3. 高风险动作必须有确认

只读操作可以宽松一点。

但只要涉及创建、修改、删除、发送、发布、扣费、影响他人，就必须进入确认流程。

Agent：我将为华东区近 30 天活跃下降超过 40% 的客户生成风险名单，并推送给客户成功负责人。是否继续？

确认不是形式主义，而是把决策权还给人。

4. 洞察型 Agent 要提前预留数据语义

如果未来要做给领导看的全局洞察型 Agent，现在就不要只围绕“工具调用”设计。

洞察型 Agent 还需要：

• 数据权限
• 指标口径
• 时间维度
• 组织维度
• 异常定义
• 证据引用
• 分层钻取
• 业务建议模板

它输出的也不应该是一段闲聊，而更像：

当前状态
关键变化
主要风险
可能原因
建议动作
可继续追问的方向

领导不需要看所有数据，领导需要知道该把注意力放在哪里。

六、Agent 的边界感比能力更重要

做 Agent 很容易被“自动化”诱惑。

但产品里的 Agent 不是越自主越好。尤其是企业产品，Agent 的核心不是“敢做”，而是“知道什么能做、什么不能做、什么时候必须问人”。

我现在会用四个维度判断一个 Agent 的风险：

越靠右，越需要权限、确认、审计和回滚。

这也是为什么我不太喜欢“让 Agent 自己规划一切”的说法。它听起来很强，但在真实产品里，很多地方都应该是确定性的。

Agent 应该负责模糊性：

理解人话
补全意图
选择能力
解释结果

系统应该负责确定性：

权限
状态
事务
校验
审计
回滚

这两者分清楚，Agent 才不会变成一个漂亮但危险的黑盒。

上线前检查清单

• 所有工具都有明确的输入 schema 和输出 schema。
• 所有写操作都有权限校验。
• 高风险动作会进入用户确认流程。
• 每次工具调用都有 trace 和审计记录。
• Agent 能解释执行计划，而不是直接执行黑盒动作。
• 工具失败后有可恢复路径，而不是只返回模型报错。
• 洞察型输出能追溯到数据证据。
• 用户可以终止长任务或撤销可撤销动作。

七、真正值得做的不是“AI 入口”，而是产品能力重组

如果一个产品接入 Agent 后，只是多了一个聊天窗口，那它的价值很快会到顶。

真正值得做的是借 Agent 反过来梳理产品能力：

哪些功能可以被抽象成能力？
哪些能力需要组合才能完成用户目标？
哪些参数经常让用户困惑？
哪些操作需要确认？
哪些结果需要解释？
哪些数据可以支撑洞察？

这会逼着产品从“页面和按钮”重新审视自己：

用户到底想完成什么？
产品到底能提供什么能力？
这些能力能不能被机器理解、组合和安全调用？

这才是 Agent 模块真正有意思的地方。

它不是在产品上贴一层 AI 皮肤，而是在产品内部建立一层新的抽象：

用户目标层
  -> Agent 编排层
    -> 产品能力层
      -> 后端服务层
        -> 数据和业务对象

当这层抽象建立起来，行动型 Agent 可以帮用户完成任务，洞察型 Agent 可以帮管理者理解现状，未来的自动化也会有更稳的落点。

所以我现在对 Agent 的判断很简单：

不要先问“我们能不能做一个聊天助手”。先问“我们的产品能力，能不能被清晰描述、被安全调用、被组合成用户目标”。

如果答案是可以，Agent 才真正有地方生长。

参考资料：

• OpenAI Agents SDK: https://openai.github.io/openai-agents-python/
• LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview
• Microsoft AutoGen: https://microsoft.github.io/autogen/stable/
• LlamaIndex Workflows: https://developers.llamaindex.ai/python/llamaagents/workflows/
• CrewAI Introduction: https://docs.crewai.com/en/introduction
• Model Context Protocol: https://modelcontextprotocol.io/docs/getting-started/intro
• Amazon Bedrock Agents: https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html
• Microsoft Foundry Agent Service: https://learn.microsoft.com/en-us/azure/foundry/agents/overview
• Google Agent Development Kit: https://adk.dev/