去年从 Manus 发展开始，Agent 元年的口号就喊响了；今年 OpenClaw 带来了小龙虾热潮，Agent 这种产品形态逐渐被大家接受。

现阶段运行的比较好的是 WorkBuddy，月活都 2000 万了，于是乎市面上层出不穷的 xxClaw 产品正在争先恐后的**“出世”**！

只不过，这其中的良莠不齐也就开始了，因为多数人、尤其是老板对Agent的理解停留在 Demo 阶段：

接一个大模型，配几个工具，做一个聊天界面，让它调用浏览器、写文档、查资料、跑代码。

然后研发在这个基础上包装一个封闭环境下的惊艳案例，于是乎老板们高潮了…

我只能说，这个探索阶段很有启发性与趣味性，但离真实生产还差很远。

因为 Agent 一旦放进生产环境，问题很快就会暴露出来：

1. 就算用户的要求明明写得很清楚，Agent 依然可能漏掉关键步骤；并且更多的时候用户的描述很模糊；
2. 工具调用错误 → 工具能够调用，但参数可能传错 → 工具问题导致修改错误的业务数据；
3. 短任务可以完成，任务稍微长一点，上下文就混乱；
4. 用户已经确认过的选择，下一次执行时还要重新询问；
5. 运行过程缺少状态，失败后只能从头再来；
6. 演示时效果很好，真正交给业务人员后却难以稳定使用；
7. …

综上，Demo 很封面，现实很骨感，现阶段已经没有人怀疑 Agent 能不能做事这件事了，大家怀疑的都是这东西会不会瞎折腾！

从今年开始，几乎所有行业的研究都其实在围绕着这个方向做展开：如何让 Agent 从一个能对话的 Demo，长成一个能稳定交付业务结果、可观测的业务生产力系统。

所以，什么是生产级 Agent？如何做好生产级 Agent？传统的业务系统，比如 SaaS 系统与 Agent 有什么关系？

我们今天就来概括性讨论下：

找场景 ＞ 选框架

传统软件是在确定的业务流程里做功能拆解：用户点击按钮，系统执行逻辑，数据进入数据库，页面展示结果。

Agent产品不同，Agent的核心能力是理解、规划和行动，它处理的是更开放、更模糊、更依赖上下文的任务，这就跟**传统意义上的“先定义功能列表，再排期开发”**有很大的不同了。

翻译下来就是：

传统产品的起点是功能，Agent产品的起点是 Use Case

所以，对应着团队工作的第一步肯定就不是选模型、选技术框架、堆能力了，而是要明确用例到底有哪些。

然后这个过程也有些行业小共识：现阶段是不存在通用 Agent 的，所以各位老板们也不要朝这个方向幻想了，先找到一个真实场景里的高价值闭环，这可能是个更好的选择：

这里的意思是：要做 Agent，先去搞清楚用户是谁、任务是什么、失败的代价是什么、用什么指标判断它做得好。

比如，我把判断一个场景是否值得做 Agent 的核心变量归纳成一个公式：

场景价值 = 任务价值 × 可执行程度 × 可验证程度 ÷ 失败风险

其中，任务价值意味着这个任务真实存在、用户已经在花时间做；可执行程度取决于是否有可访问的工具、数据和 SOP；可验证程度意味着结果好不好有明确标准；失败风险则决定你需要多强的 HITL 和治理机制。

三类典型 Agent 场景

从当前实际落地来看，Agent 场景可以被分成三类，这个分类直接对应三种完全不同的产品重心与工程重心：

一、生产力工具型

第一类是生产力工具型Agent。代表场景包括 AI Coding、AI 文档、AI 研究助手、AI 数据分析助手。

这类 Agent 的核心目标是提高个人或团队的工作效率。

AI Coding 是最典型的代表，因为代码本身就是一种非常适合模型操作的环境：输入和输出结构明确，工具链成熟，可以运行测试验证，错误信息相对可观测，修改结果可以被 diff、review 和回滚。

所以各个基模厂商选择 AI Coding 不是偶然，而是因为这个场景天然适合 Agent 闭环。

生产力工具型 Agent 的重点在工程能力和用户体验：上下文管理、工具调用、任务状态、产物管理、用户信任；

它的业务指标通常包括使用频次、留存率、任务完成率、单次任务节省时间。

二、业务流程型

第二类是业务流程型 Agent。这类 Agent 来自另一条演进路线：Workflow 到 Agent。

过去很多企业自动化是用 Workflow 做的：收到表单，判断字段，写入 CRM，通知销售，生成待办，发送邮件。

这种流程适合规则明确、分支有限、输入稳定的场景。但真实业务里，很多任务没有这么规整：客户需求描述不标准，销售要根据上下文判断优先级，客服要理解用户情绪，运营要根据数据变化选择动作。

这就是 Workflow 绕不开的致命问题：分支越来越多，规则越来越复杂，维护成本越来越高。

Agent的价值在于，它可以在一定范围内处理模糊输入、理解上下文、选择工具，并把 Workflow 不能覆盖的部分泛化掉。

业务流程型 Agent 的重点依旧是模型能力，模型基本推理能力上不来，就算是正确的输入也拿不到正确的输出，其次就是业务 knowhow 和系统集成了。

模型能力与 KnowHow 的叠加会回答以下问题：它需要理解业务对象是什么、流程节点是什么、哪些动作可以自动执行、哪些动作必须人工确认、哪些错误会造成严重后果。

这类Agent最终会导向数字员工，一个能在组织流程中承担某类工作的 Agent。

理想情况下是有任务边界，有权限，有日志，有指标，有负责人，也有被审阅和被优化的机制，实际情况下，没有日志、权限等也能工作…

三、多模态 AIGC

第三类是多模态 AIGC 型 Agent。代表场景包括 AI 图片生成、AI 视频生成、AI 海报和广告素材生成、AI 商品图生成。

这类Agent的特点是：结果更感性，评估更复杂，链路更依赖模型组合和资产管线。

它不像 AI Coding 那样容易用测试判断对错，也不像业务流程型 Agent 那样能完全用流程指标衡量。

多模态 AIGC 更关注生成效果是否好看、是否符合品牌调性、是否能批量生成、是否能稳定复用风格，业务目标常常和 Showcase 强相关。

三类场景的差异可以这样总结：

所以，在做产品判断时先问：这个场景到底是哪一类？它主要优化效率、流程，还是内容效果？它的成败指标是什么？它需要哪些工具、数据和业务经验？

在实际做的时候，**不要一开始就追求完整平台，也不要一开始就追求所有场景都覆盖。**先选一个足够具体的任务，让 Agent 能完成一次真实交付。

跑通以后，再看哪里慢、哪里不准、哪里需要人工确认、哪里需要工具化、哪里需要沉淀成 Skill…

SaaS → Workflow → Agent

SaaS、Workflow 与 Agent是一条演进链，其中SaaS 是记录系统，Agent 是认知和行动系统。

所以，结论也就出来了：**Agent 没办法凭空替代 SaaS。**它的工作，是站在已有系统、流程和数据之上，承担原本需要人类去理解上下文、做判断、推进动作的那一层工作。

这东西比单独讨论 Agent 更重要，因为它能帮助团队避免两个常见误区：

• 第一，把 Agent 当成孤立产品；
• 第二，把所有流程都幻想成 Agent。

他们彼此间的关系是：

SaaS 记录业务状态 → Workflow 执行固定流程 → Agent 理解上下文并泛化行动 → 数字员工承担一类稳定工作

传统 SaaS 的核心是记录和协作。比如 CRM 记录客户，ERP 记录资源，工单系统记录问题。这些系统解决了一个重要问题：业务状态被结构化沉淀下来。

但在真实工作中，人还要做大量认知和行动：看客户历史判断下一步怎么跟进，读工单描述判断问题属于哪一类，看项目状态判断风险在哪里，读一堆文档整理出一个结论。

Workflow 解决了一部分固定流程，但它很难处理高度变化的上下文。Agent 则补上了中间这一层：认知和行动。

所以这里问题也就来了：很多公司其实是在裸奔，他们根本没有 SaaS 系统，在这种情况下还想 Agent 运行得很好，那就奇了…

毕竟，无论 Agent 怎么逆天，他总得有个最终存放数据的地方吧，别告诉我，你准备放 markdown 文件里。

一个真实生产级Agent通常要打通四类能力：

• **外部工具。**搜索、网页、邮箱、代码仓库、第三方 SaaS；
• **内部工具。**企业自己的 CRM、ERP、工单、知识库、审批系统；
• **数据API。**用户数据、业务数据、行为数据、财务数据；
• **业务 SOP 和 knowhow。**流程规则、异常判断、专家经验、组织偏好；

这四类能力共同构成了 Agent 的 action space。

如果把任务特点和合适方案对应起来，伸出的四象限判断：

综上，Workflow 和 Agent 不存在谁替代谁的问题，而是分别承担稳定路径与开放判断；这里的核心是根据步骤明确度与失败代价来分配自由度。

生产级架构，双视角

要去看生产级 Agent 架构，可以从两个视角做展开：用户视角与工程视角：

如果从用户视角看，用户在使用 Agent 的过程中经历了什么？大概可以分成四层：

一、入口层

第一层是入口层：用户怎么触发 Agent？

最简单的入口是 Chat，但不能只有 Chat，因为真实工作不是总是从一句话开始的。所以入口可以分成：

1. **对话入口：**Chat、侧边栏；
2. **模板入口：**任务模板、Brief表单；
3. **文件入口：**上传文档、拖入图片；
4. **事件入口：**定时、Webhook、状态变化；
5. **集成入口：**IDE、浏览器插件、邮箱、飞书；

Agent 的入口越贴近用户的真实工作环境，越容易被使用。因为入口层不是 UI 问题，而是任务触发问题，所以整个腾讯 AI 体系还很有的玩，我这块是很看好微信 + WorkBuddy 生态的。

二、执行层

第二层是执行层：**Agent 在执行任务时，用户怎么知道它在干什么？**这是生产级 Agent 和普通聊天产品最明显的差异。

普通聊天产品里，用户发一句话，模型回一段话，中间过程用户看不到。但 Agent 要做任务，任务可能持续 30 秒、3 分钟，甚至更久。

这时候用户最关心的是：它理解了我的任务吗？准备怎么做？做到了哪一步？有没有出错？我能不能中途打断？

执行层的核心是三个词：可观测性。

可观测指的是用户能看到 Agent 的任务计划、执行步骤、工具调用、中间结果和当前状态。

后续又会再有衍生，比如：

• 可打断指的是用户能暂停、取消、继续、修改方向。
• 可审阅指的是在关键动作之前，Agent要把计划、参数、影响范围展示给用户，让用户确认。

这些就是可观测基础下的必要功能延伸，也是最近的明星词汇HITL（Human in the Loop）的用武场景。

PS：关于 HITL 会有很详细的设计，问太多用户会烦，问太少系统会危险，这里不展开。

三、产出层

第三层是产出层：用户最终拿到什么。

很多 Demo 型 Agent 的问题是：他们喜欢在一个封闭的环境中自嗨，这对演示没问题，对生产不够。

真实工作里的产出是一个完整的东西：文档、代码、表格、图片。

这个产出在心理预期上必须完整、必须具有一致性，不要不完整，不要相同的输入给出迥异的输出。在这个基础下还得考虑被保存与可被修改性等问题。

比如，生成的图片和报告很满意，会不会想要微调一点就很难？

四、治理层

最后是治理层：用户怎么管理Agent。

很多 Agent Demo 没有治理层，但生产级 Agent 一定要有。

治理层解决的是：一个 Agent 被团队或组织使用以后，怎么保证它可控、可信、可复盘、可改进。

其实映射起来就是第二层的基础设施，我这里说个最简单的案例大家就懂了：我们经常会抱怨自己的 OpenClaw 不够聪明，这就是一个可被改进项，我们需要路径去做这一切。

用户四层视角结束，我们再来说下工程视角，因为都是在描述 Agent 这个东西，大家映射的感觉就出来了，这里又会分为五大系统：

一、大脑系统

大脑系统，即 Model + Agent Loop。

Agent 是一个循环：观察输入、理解目标、制定下一步、选择工具、执行工具、观察结果、更新状态、决定继续或结束。

生产环境里的 Loop 会有很多策略去控制成本，比如：最大步数、最大 Token 成本、最大执行时间、工具白名单、失败重试次数、任务结束条件。

Agent Loop 是 Agent 的执行骨架，核心是控制失控。

二、行动系统

Tools + Runtime。

Tools 决定 Agent 能做什么。有 Tools，Agent 才能查资料、读文件、调 API…

所以，必要的工具是一个都不能少，但这东西也不是越多越好，因为工具越多，模型选择工具的成本越高，误用工具的风险也越高。

现阶段最危险、灵活的 Tools 就是 Coding 本身，如果不做限制，他可能会冲掉你很多真实想用的工具，所以工具的命名和描述值得反复打磨。

而 Runtime 是解决 Agent 的动作在哪里执行的问题：我们 Demo 时候不会去关注安全、权限等问题，但一旦涉及生产，这一关又是绕不过去的部分，比如 OpenClaw 不被国内使用，其中安全的考量会非常重。

三、工作台系统

这也是我们常说的记忆系统，包括：State + Context + Memory，这块也是各个 Agent 系统设计的核心难点了。

State 保存做到哪一步，有了结构化状态，系统才能支持进度展示、暂停恢复、失败重试、断点续跑等功能。

Context 组织本轮模型真正需要看到什么，除了工程能力之外还要融入不少业务 KnowHow。

Memory 决定哪些信息值得跨任务保留，比如区分用户偏好、项目事实、业务知识和执行经验等。

四、经验系统

这里的经验指的是：Prompt + Skill + Workflow。

真的做过生产级 Agent 的同学都会清晰，Agent 核心代码不会太多，那么多数时间干嘛去了，答案是两块：

• 第一是处理各种 Tools，但这个是系统内部工作，不会外放；
• 第二是插件生态或者说工作流工厂了，也就是现在的 Skills，包括实际用户使用 OpenClaw/WorkBuddy 等都是沉淀 Skills 居多；

这就是薄 Harness，厚 Skill 说法的由来了。当流程稳定到可以固化，就进入Workflow 模式，让 Runtime 管状态，不让 LLM 自己拼流程。

五、控制系统

最后是控制系统，这块跟用户视角的治理层几乎是映射的，即 HITL + Guardrails + Eval。

HITL 负责在高风险动作前让人确认，Guardrails 负责权限边界和安全防护，Eval 负责让系统可衡量、可改进。

这里每个部分都可以说很多，这里就不衍生了。

两个视角

上述就是同一个 Agent 架构在两个视角下不同的组成。

用户看到的是 Agent正在执行任务，工程里对应的是任务状态、工具调用日志、流式输出和运行时。

用户看到的是我可以中途确认，工程里对应的是 HITL 节点、暂停恢复、状态持久化。

用户看到的是它记住了我的偏好，工程里对应的是 Memory 写入策略、召回策略和上下文组装。

…

生产级 Agent 的六个阶段

上述的描述可能会让很多同学感到复杂和难以着手，其实关于一个生产级Agent是怎么长出来的，我们已经形成了非常清楚的演进路径；

大家照着这个路径走就行，也就是说一个生产级 Agent 的成熟会经过六个阶段（你说他有六个层次也行）：

一、能聊

第一阶段能聊：即只有 Chat UI、模型调用、流式输出与基础历史消息。它解决的是体验入口问题，不解决任务交付问题。

这个阶段虽然简单但非常重要，因为它决定了后面所有体验的基础，包括输入框、消息列表、流式响应、错误提示、loading状态等。

二、能用工具

在第一个基础下就可以叠加工具使用了：搜索、读文件、查数据、调用内部 API。

这个阶段的核心是 tool calling，但这里还是徐徐渐进，不要一上来接很多工具，按业务场景来，一个业务场景最少需要几个工具，就注册几个工具，跑完 3 个场景，基本框架就跑顺了。

三、能做任务

在最简单场景跑完后，系统开始引入 task、step、status 与 artifact。

用户开始看到一个完整任务在推进：任务计划、当前进度、中间产物、执行日志。

四、能跑长任务

在短任务没问题的情况下，就可以刻意引入长任务了，因为他会带来很多新问题：上下文太长、工具调用太多、执行时间太久、中途失败、用户离开页面…

要解决这些问题，就不得不引入更多的工程能力：runtime、checkpoint、compression、pause/resume、retry policy、cost tracking。

五、能被治理

长任务跑完没问题，就必须坑安全权限等硬骨头了，上线后老板的面孔逐渐会变得扭曲，因为他们会看模型成本，这时候模型切换工具、Token 成本面板也要出来。

当 Agent 开始进入团队或企业环境，没有办法不加入治理层，Agent 可以写 CRM，那就必须知道谁允许写、写了什么、为什么写、能不能回滚。

六、能沉淀能力

这块与其说对团队有效，不如说对各位更有用，大家在完成生产级 Agent 的过程中，需要把高频有效经验沉淀下来，包括工程经验的沉淀以及 Agent 各种参数的沉淀。

上述就是生产级 Agent 需要走过的六个阶段，大家走到哪里了呢？

常见问题

前面说了很多架构层面的经验，最后我们也分享一下之前实际踩的一些坑，我整理下来最常见的坑点有五类：

第一，Agent 不遵循要求

关于这个问题，现在可能不存在了，但在去年我们做架构的时候，框架是换了一轮又一轮：

先是纯 ReAct，后来把复杂动作封成 tool，再进一步改成对 Agent 友好的代码接口，随后引入 Skill，最后对稳定路径启用 workflow mode。

当 Prompt 过长还不稳定、Tool 签名越来越胖、Agent 看到代码也不调工具时，就说明单纯靠 Prompt 驱动已经走到头了…

第二，工具调用不稳定

如何防止 tool 被错误使用、参数传错、业务混乱、失败后死循环？

这里大概方向很清晰（实际处理起来会很烦躁）：工具必须名称清晰、参数少而准、输入输出结构化、危险动作需要确认，必要时不要让 Agent 手动拼底层工具链，而要直接 dispatch 到 workflow。

第三，长任务跑散

长任务容易面临上下文膨胀、执行时间过长、中途失败、用户离开页面、需要恢复等多个子问题。

大概的解法是：checkpoint、step cache、pause/resume、durable execution、artifact 与状态持久化。

这句话大家可以多琢磨：长任务如果没有状态中心，Agent 看起来像在工作，实际上每一步都像在重新开始。

第四，记不住用户偏好，也记不住项目事实

我们之前对 Memory 的使用很克制，存储时候需要区分用户偏好、项目事实、业务知识和执行经验，并且设计写入策略、召回策略与过期机制。

PS：这部分是有难度，并且每个团队不太一样的部分

第五，用户不敢把动作真的交给Agent

在我咨询的公司里面，Agent 做 Demo 是很好的，大家对 Agent 的看法也非常正面，但一旦涉及真的要把工作交给他们的时候，答案几乎就是否定的了。

要做到这一切，之前说过的可观测、可打断、可审阅就是重点了。

用户其实需要是一个可控性的感觉，倒不一定要真的可控，出了问题他们需要知道哪里错了，错的部分他们需要清楚是不是有逻辑性可言，还是完全的随机。

薄 Harness、厚 Skill

最终多数问题的处理往往都会回归 Harness 和 Skill。

Harness承载通用能力：Agent Loop、工具注册、状态管理、上下文拼装、Runtime、日志、权限与HITL；

Skill 沉淀场景经验：触发条件、任务边界、工作流步骤、工具协议、数据口径、人工确认节点、产物标准、错误恢复与评估规则。

Harness is build to detail，在业务场景里的重复失败，反过来逼出 Harness 与 Skill 的边界：

• 把所有规则都塞进系统 Prompt，系统会越来越重、越来越难维护；
• 把所有动作都继续暴露为自由工具链，ReAct 在高代价任务上就会频繁失稳；
• 把场景经验沉在代码里，又会失去版本化、复用和独立评测的能力。

观测性与自进化

Hermes 出来后，所有的 Agent 都会关注一个词：自进化，也就是能不能从失败里持续学习。

要做好这一切，一定离不开的是可观测性，而可观测性简单来说也可以分为三层：

• 第一层是工具层评测：工具有没有被正确选择、参数是否正确、错误码是否清晰、结构化输出是否合规。
• 第二层是 Skill 层评测：一个 Skill 能否从输入跑到产物，步骤是否完整，Checkpoint 是否出现，输出格式和证据链是否符合要求。
• 第三层是任务层评测：最终任务有没有完成，用户是否采纳，人工修改率是否下降，延迟、成本和安全性是否可接受。

这一块无论数据集生产还是案例核销，很多团队喜欢依赖 AI，但大家要记住：能用脚本和结构校验解决的，尽量不要交给模型。

这里举个例子，一个生产级 Skill 至少要从五个维度评估：

1. **正确性：**结果是否符合任务要求；
2. **稳定性：**同类输入下是否稳定；
3. **覆盖率：**能覆盖多少真实用户场景；
4. **成本：**Token、工具调用、执行时间；
5. **可用性：**用户是否真的采纳；

这块复杂度较高，今天也不赘述。

结语

最后总结一下，生产级 Agent 的核心目标只有一个：让模型在真实任务中稳定地完成工作。

在生产级 Agent 之前，聪明比稳定重要，但上了生产，稳定和成本就会变成首选项。

那么稳定从哪里来呢？四件事：

1. 场景足够真实： 真实场景自带约束，输入有边界，输出有验收标准。
2. 工具问题： 工具调用是 Agent 最容易出现的问题地方；
3. 可观测性： 这里就不必多说了，没有观测性就不可优化；
4. 人工补丁： 现在千万别相信 Agent 自动进化的鬼话，一般要靠人标记数据，但如果失败只靠人工打补丁，天花板就是运维团队的精力上限，这个没太好的办法；

话不多说，反正现在 Agent 的关注点已经从框架进入了深度场景使用了，大家认为呢？

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】