Agent三年进化：从问答到自主执行，小白程序员必备收藏！

一、Agent的三年演化：从问答到自主执行

回顾 2023~2026 这三年的时间，作为AI Agent应用从业者而言，会有一个明显的感觉：

“Agent 并不是慢慢变强的，而是一次次“跳级”长大的。

笔者有幸完整参与了这几个阶段的演进，并分别推出了对应的 AI Agent 方案，以下回顾一下这三个阶段的演进历程。

1、问答Agent（被动式 ReAct）

2023年是LLM爆发的元年，也可以说是 Agent 概念的启蒙期。这一阶段的典型架构为 LLM + Planning + Tools + Memory，核心范式是基于 ReAct（Reasoning + Acting） 的被动响应机制。

早期阶段的 Agent 基本上有几个特点：

交互形态：增强型 Chatbot，以“一问一答 / 指令—执行”为主。常见实现方式是在企业软件的功能界面旁新增 AI 输入框，用于触发单点任务。
能力边界：高度依赖明确指令，仅能完成短链路、低复杂度的单点任务，如 AI 筛选客户、AI 润色文本等。
局限性：缺乏长期规划能力，任务链条一旦超出上下文窗口或逻辑深度，极易出现偏离或中断。

简言之：Agent 并不具备“把事做完”的能力，只能完成“被定义好的那一步”。

2、工作流Agent（工程化约束）

进入 2024 年，随着 Agent 向 ToB 场景渗透，稳定性成为落地的主要瓶颈。

纯 ReAct 架构在复杂业务场景中表现不可控，促使Agentic Workflow 成为主流。

以扣子、Dify 为代表的平台，实质上是通过工程化手段来弥补模型的不确定性。

这个阶段的 Agent 主要是如下几个特点：

运行机制：由人工进行任务流程编排，LLM 主要作为一个运行节点存在，主要负责意图识别、语义理解与数据加工等任务。
应用场景：适用于高频、规则清晰、容错率低的业务流程。笔者25年围绕这部分场景推出了几款Workflow Agent，有机会将在后续文章跟大家做分享与拆解。
价值体现：以牺牲部分灵活性为代价，换取高可控性、高可解释性和稳定效果下限，是当前 ToB 领域性价比最高的落地形态。

这一阶段确立了企业级 Agent 的一个重要共识：在工程能力足够成熟的场景下，确定性优于智能上限。

3、自主Agent（复杂规划与长程任务）

2025 年标志着 Agent 从“辅助者”向“执行者”的角色跃迁。主要表现在Manus、Claude Code、Codex 等产品验证了 Agent 在复杂任务上的可行性。

2026 年 OpenClaw 的流行，在国内牵起了“全民养虾”的热潮，则进一步扩大了自主 Agent 的技术共识与受众基础。

这一阶段的 Agent 主要特征如下：

核心变化：不再依赖逐步指令，而是以用户目标为导向进行任务拆解与路径规划。
长程执行：支持多轮工具调用与迭代，能够完成跨模块、跨系统的复杂任务。
自我校验：通过轻量级 Harness 或自反思机制，在运行过程中持续纠偏，保障最终结果质量。

随后出现的 Hermes 等框架，进一步引入自进化能力：Agent 在任务完成后，会将过程中的经验沉淀为策略，用于优化后续行为。

这标志着 Agent 从“执行工具”向“具备成长性的数字员工”迈出了关键一步。

三种范式的并存与融合

回过头看，这三次变化给笔者的感觉是：

问答 Agent：像实习生，需要一步步指导
工作流 Agent：像操作员，流程清楚、执行稳定
自主 Agent：像项目负责人，用户只管给目标

但它们从来不是替代关系，而是互补的。在实际落地中，往往是：

用自主 Agent 做总调度
用工作流 Agent 跑确定性流程
用问答 Agent 做交互入口

接下来，笔者将分享一个自主Agent在企业级软件的探索和落地案例。

二、用“龙虾”架构重构 AI 员工平台

2026 年初，随着OpenClaw（俗称“龙虾”） 架构的兴起，我们清晰地看到下一代 AI 员工的核心形态：

一个能够自主调用工具、串联流程、完成复杂任务的执行体。

基于此判断，团队迅速立项，以“龙虾”类架构为底座，对现有 AI 员工平台进行重构。

1、重构前的现实：名义上的 AI 员工，实质上的问答助手

在重构之前，我们的“AI 员工”平台，本质上仍停留在知识库问答阶段：

用户可在平台上配置默认参数、挂载知识库
AI 的能力边界被限制在“回答问题”
无法直接驱动业务流程或完成跨模块任务

这导致一个尴尬的现实：产品名为 AI 员工，实际只是一个更聪明的客服。

2、底座框架选型：安全与轻量优先

在前阶段的“百虾大战”中，不少软件厂商选择直接将 Open Claw 打包进安装程序。

我们最初也沿这一路线推进，但在深入评估后发现：

Open Claw 偏向功能堆砌，默认安全策略宽松
集成后软件安装包容量膨胀 5 倍以上
与企业级环境对安全性、轻量化的要求存在冲突

随后我们也评估了 Zero Claw（Rust 实现），虽然在轻量化和安全性上表现优秀，但受限于迭代节奏不稳定，难以支撑长期使用。

最终，我们选择 QwenPaw 作为底层框架，主要基于三点判断：

企业级特性完善：权限控制、审计日志、安全策略开箱即用
开源且持续维护：每周一更新的稳定迭代节奏
生态契合度高：与现有 CRM 架构和运维体系兼容良好

这为平台的长期稳定性奠定了技术基础。

3、系统接口全面 CLI 化：让 Agent 真正“可用”

仅有框架并不足以构成差异化竞争力，因此我们第二步主要是：让 Agent 拥有操控 CRM 业务能力的“手”和“脚”。

（1）核心理念：业务能力的 CLI 化

我们将 CRM 中大部分业务功能改造为 CLI（命令行接口），并进一步封装为原子化 Skill，供 Agent 调用。

在原子能力之上，再组合出面向具体场景的复合 Skill，例如：

线索初筛与跟进 Skill：自动完成线索清洗、初步触达、质量评分与分配打标
智能拜访策略生成 Skill：结合联网搜索与客户历史轨迹，生成个性化拜访方案与执行清单

（2）为什么是 CLI，而不是 GUI？

过去几十年，CRM 的核心命题是：

让销售把数据录进来，然后系统地管理这些数据。

GUI 时代的 CRM 要求销售适应系统：打开表单 → 填写字段 → 提交保存。

这一过程重复、繁琐，直接导致销售抗拒录入，进而陷入“数据越少 → 价值越低 → 使用意愿越弱”的负循环。

AI Agent 提供了一种完全不同的解题思路：

它不需要人类操作界面，而是直接进入系统内部读写数据。

而 CLI 恰好是 AI 的“母语”：

大语言模型在预训练阶段已接触海量命令行语料
CLI 是纯文本协议，无需视觉理解或界面解析
命令与结果的语义关系清晰，便于 Agent 推理与规划

一句话总结：CLI 是 AI Agent 的原生交互方式，GUI 则是它需要费力翻译的外语。

（3）安全约束设计

为避免 Agent 的不确定性对企业数据造成风险，我们在 CLI 层做了严格限制：

禁止删除操作：仅开放增、改、查能力
敏感操作二次确认：关键业务动作需用户显式授权
Skill 级别的行为约束：通过 Skill 定义明确边界，防止越权执行

4、计费模式重构：从“包年”到“套餐 + 按量”

在原有 AI 产品中，我们采用包年订阅制（如 300 元/账号/年）。

这种模式成立的前提是：单次调用的 Token 消耗是可预测的。

但在自主 Agent 场景下，这一前提被打破：

用户提问是高度主观的
Agent 会自动规划多步任务，调用次数和复杂度不可预估
Token 消耗呈指数级波动

为此，我们推出了 “席位订阅 + 按量计费”的混合模式：

每个席位完成订阅后，按月赠送固定额度的 AI 资源包
额度用尽后，可按需购买加量包
整体结构类似手机流量套餐

这一设计既保留了订阅制的稳定性，又规避了不可控 Token 消耗带来的经营风险。

5、产品形态：从“功能模块”到“AI 员工组织”

经过底座重构与 CLI 化改造后，我们的 Agent 平台不再只是“问答助手”，而是一个可供用户自由组装 AI 员工的操作系统。

（1）AI 员工作为产品的基本单元

在平台上，用户可以围绕具体业务需求，搭建属于自己的 AI 员工，并通过Skill 绑定 明确其职责边界。例如：给某 AI 员工赋予客户管理 + 订单管理 的 Skill，该 AI 员工便专注于客户全生命周期的管理与转化工作。

Skill 的组合方式，决定了 AI 员工的岗位属性：有些像“销售助理”，有些像“客户成功经理”，有些像“运营分析师”。

（2）多智能体调度：主 Agent + 子 Agent

单个 AI 员工的能力始终有限。真正体现自主 Agent 价值的是：多智能体协同机制。平台支持由主 Agent 统一承接用户指令，并完成以下工作：

任务拆解：将复杂目标拆分为可执行子任务
路径规划：确定子任务的执行顺序与依赖关系
智能分配：根据 Skill 归属，将任务分配给对应子 Agent
结果汇总：整合各子 Agent 的输出，形成最终交付物

这使得用户不再需要关心“谁来做、怎么做”，只需关注“要达成什么结果”。

（3）产品演示：一个端到端的真实场景

为了更直观地理解这套形态，以下是一个已经在平台上跑通的典型场景。

用户通过微信向 AI 员工下达指令：

“帮我给昨天刚添加的欧汶打个电话，

整理他们对 CRM 系统的需求，并约个上门拜访时间，

顺便围绕沟通内容给我整理一份企微的拜访策略文档。”

AI 员工的执行过程如下：

第一步：任务拆解

识别关键动作：打电话 → 需求整理 → 预约拜访 → 生成文档

第二步：动态调用内部 CLI 工具

客户筛选：定位“欧汶”
AI 外呼：自动拨号并完成初步沟通
沟通分析：提炼客户关键需求与关注点
写跟进记录：将沟通总结写入 CRM
创建待办：新增明天拜访欧经理的待办任务

第三步：动态调用外部 CLI 工具

企微文档编辑：生成结构化拜访策略文档

第四步：结果交付

返回待办创建成功的通知
同步拜访策略文档至用户企业微信空间