从概念到落地：有赞 Agent 应用与探索

本文内容来自 2025.5.22 有赞 Menlo发布会 CIO & 大模型研讨会专场分享，分享人余晖。全文约4600字，预计阅读时间10分钟。

1 引言
2 Agent相关概念

2.1 什么是 Agent
2.2 Agentic System 的组成部分
2.3 Multi-Agent 系统的设计原则

3 有赞的 Agent 实践案例

3.1 智能助手（加我助手）
3.2 智能销售

4 AI 时代的挑战和实践

4.1 产品研发面临的四个「不知道」
4.2 软件范式的根本性变化
4.3 以数据为中心的研发模式

5 结语：Agent 技术的未来展望

文末有个招聘彩蛋，记得看到最后哦！

1 引言

Agent 技术正在成为 AI 领域的热门关键词。2023 年至今，arXiv 上含「agent」关键词的论文数量持续攀升，2025 年截止到 4 月每月近千篇；工业界则先后涌现出 LangChain、CrewAI、LlamaIndex等数十种框架，并催生了编程、金融、法律等各种通用和垂直的 Agent 产品。

图 1：Agent 技术生态繁荣，各类框架层出不穷

作为技术人，我们不仅关注概念本身，更关注如何将其落地为实际业务价值。本文将分享有赞在 Agent 领域的实践经验，从技术原理到业务应用，展示我们如何在零售 SaaS 场景中探索 Agent 技术的实际价值。

2 Agent相关概念

2.1 什么是 Agent

当我们谈论 Agent 时，究竟在谈论什么？有趣的是，即使在 Agent 大爆发的今天，关于其定义仍然没有明确共识。在研究过程中，我们接触过至少30种不同定义，比如：

前OpenAI安全主管 Lilian Weng：

Agent = LLM + planning + memory + tools

LangChain：使用LLM决定控制流的系统

OpenAI：能够独立为用户完成任务的系统

每家公司都声称自己在做 Agent，但每家做的 Agent 又各不相同。最近 OpenAI 在《A practical guide to building AI agents》中隐晦指出， LangChain 的 LangGraph 框架是一种对于 Agent 的过度抽象，LangChain CEO公开回应这个指责，还引发了很多开发者在 Twitter 上关于 Agent 的讨论。

与其争论什么是「真正的」Agent，不如承认系统有不同的智能程度（agentic system），就像自动驾驶汽车有不同的自主程度一样。

图 2：Agent 与环境的交互模型

尽管定义各异，基本共识是：Agent 是一种有目标、基于环境的决策系统。与 LLM 最大的区别在于，Agent 可以与现实世界交互，从感知环境开始，做出决策并执行，影响环境，然后基于反馈调整，不断迭代循环。

2.2 Agentic System 的组成部分

一个完整的 Agentic System 包含四个核心部分：

感知：为模型构造上下文。最常见的是 RAG（检索增强生成），也可以查询结构化信息（数据库、网页）或检索历史记录（记忆）。
决策：本质是规划。可以通过规则构建（workflow），也可以通过 LLM 驱动（自主 agent），或借助外部规划器。设计时需权衡泛化性和正确性——LLM 驱动泛化程度高但不确定性大，workflow 泛化程度低但更可控。
执行：调用工具改变环境。包括 API 调用（Rest、RPC、SQL、函数调用）或 RPA 整合图形软件（如 Anthropic 的 Computer use）。
反馈：评估和迭代机制。可通过人类标注、规则或模型生成，更新可以是离线或在线的。

图 3：Agentic System 的四个核心组成部分

这个闭环构成了 agent 的基础单元（building block）。复杂 Agent 由小 Agent 构成，符合业务逻辑——大决策由一系列小决策构成。

2.3 Multi-Agent 系统的设计原则

Agent 互相调用和协作构成 Multi-agent 系统，但设计时需谨防过度拆分。一个 Agent 应代表一个业务决策点，可通过持续反馈优化。

什么时候需要 Multi-agent？可从分布式系统借鉴思路。把 Agent 比作计算机：LLM 是 CPU、Context window 是内存、向量数据库是硬盘、tool 是程序。分布式系统解决三个问题：

性能不足：单机计算/存储不够（如 Hadoop、Flink）

容错：单系统易出问题，需多系统协同

协作：不同团队负责不同微服务

图 4：Multi-agent 系统设计原则

Multi-agent 系统也是如此，主要解决单次 LLM 调用智力不足的问题，其次是容错和协作。系统架构应从单 Agent 开始，在必要时才过渡到多 Agent。

3 有赞的 Agent 实践案例

下面介绍一些有赞的 Agent 实践案例，简单分享下加我助手和智能销售两个项目：

3.1 智能助手（加我助手）

加我助手的演进遵循了从单 Agent 到 Multi-agent 的路径：

初始阶段：仅有产品问答模块，使用简单 RAG
技能扩展：添加多种技能，但用户需手动切换
意图识别：开发意图识别 Agent，仍为单 Agent 架构
多 Agent 体系：场景复杂化 + 多团队协作需求

图 5：加我助手的迭代演进

除架构演进外，我们还进行了技术优化：

RAG 优化：增加查询改写功能，提高系统鲁棒性。用户不一定会提出完美问题，通过查询扩展和改写，系统能更好处理各种输入变化。

知识图谱：引入 GraphRAG 技术，将产品知识问答准确度从 76%提升到 93%。对算法实力一般但工程能力强的团队，知识图谱是模型后训练的实用替代方案。

强化学习：经营分析场景中，将评价体系（如 AARRR 模型）转化为强化学习的奖励函数，实现模型持续优化。

图 6：经营建议场景下的强化学习

当然我们也在经营分析场景上基于 SFT 和强化学习进行微调，这个时候我们之前基于经营分析 Agent 构建的数据集和评价体系，天然就过渡到了 RL 领域的环境和奖励函数的构建。之前我们在评价一个经营建议好坏的一个重要指标是思考过程是不是符合 AARRR，那么现在做 RL 的时候的奖励函数之一就是其思考过程是否符合 AARRR。

3.2 智能销售

我们在过去的一年时间里一直试图想要通过 AI 技术来改善我们自己的销售过程，提升销售业绩。

在有赞这类 B2B 的销售场景里，销售链路比较长。整个过程有线索挖掘、意向判断、挖掘需求、邀约演示、报价成交等多个阶段。整个过程我们通过自动拉群和通过 AI 的意向判断和需求挖掘，整体的线索转出率比人工高了 10 个百分点，并且让原先的 SDR 线上团队的人数从 10 个人减少到 2 个人，并且这两个人只需要负责检查质量和做应急处理即可。