上个月我这边非常忙碌接了个不算轻松的活为某企业系统性的介绍了什么是生产级 Agent。懂的同学都会明白这种面向产研团队的培训是很难做的好在最后圆满结束也取得了不错的效果整个这次培训前前后后进行了 6 场分别讨论了框架、架构、Skill、Tool、AI 原生组织以及 Agent 人才要求。这些话题的设计我这边是有深意的背后其实围绕着同一个问题Agent 进入企业之后究竟应该做什么又该怎样做成一个可以长期运行的生产系统其实现在很多企业都会有这种需求因为更多的团队已经可以快速做出 Agent Demo但他们的手法都非常类似接入一个大模型配置几个工具增加知识库再做一个聊天界面。可一旦进入生产很多小问题就出现了如果没有生产级的经验往往会摸不着头脑比如Agent 应该独立做成一个产品还是放进原有系统哪些场景适合 Workflow哪些场景适合 AgentTool、Skill、MCP、知识库分别承担什么职责Agent Loop 跑起来以后还需要补哪些工程能力多 Agent 究竟解决了什么问题企业应该怎样管理一个长期运行的 Agent产品经理和工程师需要具备哪些能力这些问题每一个都不太难但只要判断错一个就容易产生不低的试错成本所以花点小钱取取经也是很有必要的。今天我就把之前 6 次培训偏理论的部分分享给大家希望对大家有用Agent 在企业的定位理解 Agent首先要看它和现有软件系统之间的关系。传统企业软件承担的核心职责可以概括为 System of Record记录系统。CRM 记录客户、线索、订单和合同ERP 记录库存、采购、销售和财务项目管理系统记录需求、任务、负责人和进度飞书文档看起来更加自由每一行文字依然在记录某类业务事实。这些软件帮助企业保存信息、管理对象、维护流程并保证企业拥有一份相对可信的事实记录。Agent 增加了一个新的软件层认知与行动层。用户可以直接提交任务例如帮我分析最近一个月的销售线索找出高价值客户生成跟进建议并把结果更新到 CRM。Agent 接到任务后需要完成几件事理解用户的意图组织当前任务需要的上下文判断可以使用哪些工具调用不同系统完成操作检查执行结果把最终结果写回业务系统。原来需要用户打开多个软件、查找数据、复制信息、执行操作。现在用户把任务交给 Agent由 Agent 完成中间过程。企业软件由此可以分成三层用户入口与交互层 认知与行动层 业务记录层。Agent 的价值主要取决于两个指标完成了多少任务完成的任务有多大价值。企业最终关心的是交付结果除此之外的聊天次数、调用工具数量、生成内容长度都只能算过程指标。为什么是 AI Coding早期的大模型应用主要集中在聊天、知识库。聊天解决信息生成问题RAG 解决知识检索问题而需要完成具体任务更多还是依赖工作流Workflow 通过人工编排实现固定流程。AI Coding 出现以后模型开始在一个相对完整的环境里持续行动Agent 的能力也率先在编码场景里得到验证。Coding Agent 拥有几个天然条件1. 上下文相对清晰代码、依赖、配置、文档和项目结构都在仓库中。模型可以读取文件也可以通过搜索快速定位信息。大量训练材料又来自 GitHub、技术文档和开源项目模型对代码世界已经比较熟悉。2. 工具天然存在Coding Agent 可以直接使用终端、文件系统、搜索命令、编译器、测试框架和 Git。它不需要等待每个业务系统重新开放接口电脑已有的基础工具就足以支持大量操作。3. 验证机制比较完整代码是否可用可以通过编译、测试和运行结果进行验证。模型写完代码以后可以执行测试发现问题后继续修改形成清晰的反馈循环。4. 恢复成本较低代码有 Git可以查看差异、保存版本和回滚修改。即使 Agent 做错了也有机会恢复。线上业务、线下服务通常缺少这种恢复能力。已经发出的邮件、已经提交的付款、一次错误的客户沟通都很难直接撤销。综上Coding Agent 提供了一个适合模型持续行动的环境上下文清晰、工具丰富、结果可验证、过程可反馈、错误可恢复。Manus 早期使用 CodeAct也延续了类似思路把大量行动转换成代码再通过运行环境完成任务。Codex、Claude Code 等产品同样在扩大任务范围希望承接更多通用工作。因此Coding Agent 可以看作 Agent 产品的早期优势场景也是观察通用 Agent 演化方向的重要窗口。Workflow 还是 Agent很多企业一看到 Agent 热度上升就希望所有项目都采用 Agent 架构。技术选型仍然需要回到具体业务。这里可以使用两个维度判断横轴业务知识的专业程度纵轴工具数量、行动次数以及循环推理次数。固定流程适合 Workflow如果任务步骤清楚、规则稳定、异常较少Workflow 通常更合适。例如收到表单后发送通知每天定时汇总数据根据固定字段生成报告按照规则完成审批流转。这类任务没有太多动态推理需求通过流程编排可以获得更稳定的结果也更容易控制成本。专业知识场景需要知识工程当任务的行动次数不多业务知识比较重时重点会落在知识库、Skill、本体和知识图谱上。普通知识库解决有哪些资料的问题Skill 补充这些资料应该怎样使用本体负责定义业务对象、属性、关系和可执行动作。知识图谱也无需强制使用图数据库。MySQL 同样可以保存对象、属性、关系与 Action。关键在于知识是否被结构化模型能否在合适的任务阶段取到需要的信息。通用复杂任务适合通用 AgentDeep Research、Coding Agent、WorkBuddy、通用办公助手都需要多轮行动和持续判断。它们面对的业务知识相对通用核心挑战集中在任务拆解、工具选择、上下文管理以及多轮执行。专业复杂任务需要业务型 Agent金融、法律、医疗、客服等场景通常同时具备专业知识和多轮行动。Agent 每执行一轮都可能需要重新注入当前阶段相关的业务规则、客户信息、历史记录和权限约束。这类系统的难点已经超过简单的模型调用知识工程、流程设计、工具体系和治理机制都需要参与。Agent 产品形态Agent 的产品形态没有统一答案企业需要先判断场景、用户以及最终交付方式垂直能力可以放进成熟产品如果 Agent 主要服务已有业务例如 CRM 中的客户分析、项目系统中的需求拆解、客服系统中的回复建议可以直接在成熟产品里增加一个入口。现有产品已经拥有用户、数据、权限和业务流程Agent 更容易接入真实场景。通用能力可以做成独立产品如果目标是服务多个部门或者希望成为公司的统一任务入口独立产品更方便扩展。独立 Agent 可以连接多个业务系统建立统一的任务中心同时承载权限、日志、工作区和成果管理。Web、桌面端和 CLI 各有位置Web 产品开箱即用部署和更新也比较方便所以早期 Agent 产品大量采用网页形态。桌面端可以获得更多本地上下文包括文件、应用、浏览器状态和操作系统能力。Claude Code 等产品让行业重新看到本地环境的重要性。CLI 适合开发者和专业用户。商业化时可以通过 API Key 完成身份识别、计量和收费。企业场景很可能形成混合结构桌面端负责获取本地上下文和执行本地操作云端负责连接业务系统、保存企业资产和管理权限SaaS 系统继续保存业务事实Agent 负责理解任务和组织行动。稳定性问题Agent 承接的任务越重要用户越关心执行过程。一个可以稳定交付的 Agent 产品需要帮助用户回答几个问题它准备做什么它正在调用哪些工具它访问了哪些数据哪些操作已经完成哪些步骤需要人工确认出错以后能不能追踪和恢复因此产品设计中需要加入以下能力1. 工具链路透明用户应该看到 Agent 使用了哪些工具、输入了什么关键参数、得到了什么结果。敏感信息可以隐藏但执行路径需要能够解释。2. Human in the Loop高风险动作需要人工确认例如对外发送信息修改关键业务数据删除文件支付或退款发布内容执行不可逆操作。人工确认还可以放在计划阶段、关键节点以及最终提交阶段。3. 行为监测和回溯系统需要保存任务日志、工具调用、上下文版本、输出结果和异常信息。只有过程可追踪团队才能定位问题用户也更容易建立信任。4. 清晰的成果区随着 Agent 能力提升用户关注的重点会逐渐集中在任务进度和最终成果。代码编辑器关注文件和代码Codex 一类产品突出对话、工具调用和成果Workspace 型 Agent 更强调目标、任务、进度和交付物。未来很多 Agent 产品会同时提供几种视图对话视图执行过程视图项目或 Workspace 视图成果视图。用户提出目标后可以减少对每轮对话的关注把精力放在进度、异常和结果上。多 Agent 相关问题多 Agent 要先区分产品设计和技术实现团队讨论多 Agent 时产品经理和工程师经常在讨论两件不同的事情产品侧关注用户是否需要认识多个长期存在的 Agent。例如一个企业可以配置人事 Agent财务 Agent写作 Agent客服 Agent。每个 Agent 拥有自己的身份、工作区、历史任务、权限和长期上下文。用户遇到不同类型的事情会主动找到对应的 Agent。划分依据主要是上下文和职责边界。公众号、小红书和短视频文案通常共享大量背景资料。产品层没有必要为每种渠道配置一个 Agent一个写作 Agent 配合不同 Skill通常已经足够。技术侧关注任务执行过程中是否需要 Sub-agent 或 Agent Team。主 Agent 可以临时创建子任务让多个 Sub-agent 并行搜索、分析或执行最终把结果汇总回来。这种多 Agent 主要用于并行处理隔离上下文控制权限划分复杂任务结构化汇总结果。用户是否需要感知这些 Sub-agent是另一个产品选择。因此多 Agent 设计可以先回答两个问题用户是否需要长期认识多个角色当前任务是否需要多个执行单元协作第一个问题决定产品形态第二个问题决定运行架构。Agent 需要哪些技术层一个基础 Agent Loop 的代码并不复杂。用户提交任务模型判断是否调用工具运行环境执行工具再把结果交给模型。循环持续进行直到模型输出最终答案。这些东西看起来很简单但一上生产就完蛋生产系统需要补齐更多能力。可以将整体架构划分为以下几层1. Agent Loop这是最基础的循环用户提出任务→ Harness 组装上下文→ 模型进行判断→ 返回 Tool Call 或最终结果→ Runtime 执行工具→ 工具结果交回 Harness→ Harness 重新组装上下文→ 模型继续执行最小版本可以只完成一次 Function Calling。复杂任务需要支持多轮循环、任务终止、异常重试和状态保存。2. Tool 层Tool 提供 Agent 可调用的行动能力包括文件读写搜索浏览器操作数据库查询企业系统 API本地命令MCP 提供的外部工具…3. Context 层Context 决定每次模型调用时模型能够看到什么。常见内容包括System Prompt用户任务历史消息Agent 身份用户资料当前计划工具说明Skill 描述中间成果业务知识权限信息。模型能力相同的情况下Context 的质量会直接影响 Agent 的表现。4. 编排与会话管理长任务需要保存当前状态例如已经完成哪些步骤正在处理哪个子任务生成了哪些文件哪些操作等待确认失败后应该在哪里继续。会话管理还要处理历史压缩、上下文窗口、任务恢复和多轮协作。5. Skill 与插件层Skill 用来沉淀任务方法、业务 Know-how、操作手册、脚本和模板。插件层负责让能力可以安装、卸载和复用。6. 观测与评估生产系统需要记录每轮模型调用Token 消耗工具调用执行时间错误信息用户反馈最终成果任务完成率。评估系统需要判断 Agent 是否完成任务、结果是否正确、成本是否合理。7. 任务与调度长时间运行的 Agent 还需要定时任务Heartbeat后台队列超时处理失败重试状态恢复任务通知。8. 治理层Agent 具有持续存在的身份和工作区。进入企业以后可以按照组织成员的管理方式配置身份权限数据范围审阅机制行为日志成本额度风险策略负责人。这部分决定了 Agent 能否进入高价值业务。Harness 究竟负责什么至此就可以稍微深度点聊聊什么是 Harness 了这个词现在被提及的频率挺高。可以将它理解为模型外围的一整套运行机制最小 Harness 可能只有 ReAct Loop生产环境还会增加 Context、Permission、Memory、Hook、Tool、Skill、状态管理和异常处理。Harness 的核心任务是在每一次模型调用前组装合适的 Context并在模型返回后推动任务继续执行。我们在实际调试 Agent 时发现大量问题都出现在 HarnessTool 描述不清晰参数定义模糊System Prompt 内部存在冲突Skill 触发条件写得不准确历史消息污染当前判断某个遗留 Hook 阻挡了操作工具结果过长挤占上下文权限信息没有及时更新。模型经常成为第一个被怀疑的对象可顺着 Trace 检查以后问题往往集中在上下文装配和执行环境调试生产级 Agent最好先查看完整链路模型实际收到了哪些消息工具名称和描述是什么模型为什么选择这个工具Runtime 实际执行了什么工具返回了什么内容下一轮 Context 如何组装哪条规则影响了最终判断有了完整 TraceAgent 才能被持续优化。ToolsTool 本身可以理解为一张可调用能力的说明书。它通常包含NameDescriptionParameters返回结果错误类型。模型读取 Tool 的名称、描述和参数然后判断是否调用。实际执行发生在本地主机、云端 Runtime、浏览器或企业系统里。例如用户询问上海天气。没有天气工具时模型只能依据已有知识回答或者明确表示无法获取实时信息。配置天气工具后模型会读取工具说明生成类似下面的调用{ city: 上海}Runtime 查询天气服务再把温度、天气状态和时间返回给模型。模型根据工具结果生成用户可以理解的答案。整个过程中模型负责推理和决策Runtime 负责执行。因此Tool 设计至少要关注四部分声明工具名称和 Description 要准确表达用途。描述模糊会直接影响模型选择。输入参数尽量结构化避免让模型自由拼接复杂文本。必填项、格式和取值范围都需要清楚。执行执行环境需要处理权限、超时、失败重试、幂等性和异常。输出结果应该方便模型继续判断。大量无关日志、过长文本和混乱字段都会增加模型理解成本。Tool 数量增加以后还需要解决工具冲突、相似工具选择、权限隔离和动态加载问题。正常情况下一个团队后端隐藏最多的工作就是做各种 Tools 和 CLI 改造前端工作最多的是构建 Skills 生态SkillsSkill 可以看作一种能力组织格式。一个 Skill 通常是一个文件夹核心文件为 SKILL.md同时可以包含skill/├── SKILL.md 描述任务目标、适用场景和执行步骤├── references/ 保存操作手册和详细资料├── scripts/ 保存可以直接执行的脚本└── assets/ 保存模板、样式和可复用物料。Skill 没有强制要求复杂协议。很多实现会先把 Skill 的 Name 和 Description 提供给模型当模型判断当前任务需要该能力时再读取完整内容。例如我作为产品经理经常需要阅读代码。于是可以编写一个代码解释 Skill找到指定代码增加中文块注释增加关键行内注释解释主要调用链标记需要重点关注的逻辑。再比如公众号文章抓取 Skill。它除了包含操作步骤还可以附带 Python 脚本。模型识别到公众号链接以后按照 Skill 说明运行脚本把文章转换成 Markdown。飞书多维表格 Skill 则可以把大量 API 操作说明放在references中。模型只在需要时读取对应章节减少每次注入的上下文数量。Tool、Skill、Pipeline 和 Agent 的区别概念解决的问题ToolAgent 可以执行什么动作Skill某类任务应该怎样完成Pipeline谁在什么阶段使用什么能力完成交付Agent谁长期承担这类任务例如写公众号文章Tool读取文件、搜索资料、生成图片、保存文档Skill选题方法、文章结构、标题规则、排版规范Pipeline选题、资料整理、初稿、审阅、配图、发布Agent长期负责写作任务的写作助手。不同的 Tool、Skill、Harness 和 Prompt 组合会形成不同类型的 Agent。Chatbot、Deep Research、Coding Agent 的模型可能接近最终表现差异主要来自能力配置和运行环境。Skill 和 Pipeline 必须配合Skill 代表能力Pipeline 代表交付过程。会写标题是一项 Skill每周完成三篇公众号文章则需要完整 Pipeline。一个内容生产 Pipeline 可能包含收集近期素材筛选选题生成文章提纲调用写作 Skill调用审阅 Skill生成封面人工确认发布并记录数据。Pipeline 需要明确当前处于哪个阶段每个阶段由谁负责使用哪些 Skill 和 Tool输入和输出分别是什么失败后如何处理哪些节点需要人工确认。企业落地 Agent 时经常投入大量精力编写 Prompt却没有定义任务交付管线。结果就是 Agent 单次表现不错长期交付依然不稳定。生产级 Agent一个 Agent 产品通常会经历几个能力阶段第一阶段能够聊天系统可以接收用户问题调用模型并输出答案。这个阶段主要验证模型和基础交互。第二阶段能够调用工具Agent 可以读取文件、查询数据、连接业务系统并根据结果继续判断。此时已经形成最小 Agent Loop。第三阶段能够规划并产出成果Agent 可以拆解任务、维护计划、生成文件并在成果区展示结果。用户开始把完整任务交给 Agent。第四阶段能够长时间运行系统加入任务队列、Heartbeat、断点恢复、重试和通知Agent 可以处理几分钟、几小时甚至更长的任务。第五阶段能够被治理企业为 Agent 增加身份、权限、审阅、日志、成本控制和风险策略。它可以接触更加重要的数据与业务动作。第六阶段能够沉淀能力团队将成功经验整理成 Skill、模板、工具和评测集Agent 的能力可以复用也可以持续迭代。Demo 通常只覆盖前两个阶段。生产系统的大部分工程工作集中在后面四个阶段。前面是关于 Agent 的架构知识那么要做这种业务需要个什么样的团队呢AI 原生组织相应着如果把视角扩大到 AI 原生组织可以重点关注四层Context Layer企业需要汇聚完成任务所需的信息。当数据、文档、历史决策和业务状态散落在不同系统里Agent 很难形成完整判断人也需要付出大量内部交易成本。Context Layer 负责连接这些信息并根据任务动态装配。Pipeline LayerPipeline 描述任务怎样在组织里流转。它需要定义角色、阶段、输入、输出、状态和交付标准。很多传统 SOP 可以在这一层被重新整理。Skill LayerSkill 保存组织的做事方法包括专业知识 操作手册 判断规则 分析框架 代码脚本 交付模板。员工经验经过整理以后可以转化为 Agent 能够调用的能力。Agent Governance Layer企业把 Agent 作为持续运行的执行单元进行管理为它配置身份、权限、日志、审阅和责任边界。操作系统可以作为组织总线人持续提供 ContextAgent 按照 Pipeline 调用 Skill 和 Tool最后把结果写回记录系统。这样形成的系统需要具备三个特征可运行可验证可迭代。业务的恢复能力不同业务对 Agent 的容错要求差异很大。纯线上软件业务通常拥有日志、版本、数据库备份和 Git恢复能力比较强。线下业务、资金业务、医疗操作和对外沟通的恢复成本更高。恢复能力较弱的业务需要增加更多控制机制执行前预览分级授权关键节点确认沙箱环境版本管理操作留痕人工接管回滚方案。技术团队不能只看 Agent 能否完成任务还要评估它做错以后会发生什么。高风险场景可以先让 Agent 负责分析、建议和准备材料由人完成最终提交。随着评测数据积累再逐渐开放部分执行权限。对应着对团队的要求会更多组织结构会怎样变化目前大部分企业的组织调整仍处于早期阶段。部分团队开始合并前后端岗位产品经理也会进入代码仓库修改内容测试职能是否完全合并仍有较大差异。很多产品经理已经使用 AI 写代码同时仍然需要编写 PRD、推动协作和处理业务问题。短期内企业更可能先改变工作边界再调整岗位名称。例如产品经理承担更多原型和代码工作工程师参与更多需求定义业务人员可以直接构建简单自动化测试人员建立 Agent 评测体系项目经理负责人与 Agent 的协作流程FDE 同时承担场景理解、方案设计和落地交付。组织变革不会只由工具推动还会受到业务风险、管理机制、评价体系和员工能力的影响至此我们就走完了从架构 → 组织 → 人才的闭环了具体对人才的需求招聘的起点通常是业务缺口。公司先明确业务目标例如增长、商业化、客户交付或平台支撑。随后判断缺少什么能力再决定设置哪类岗位。一个相对完整的招聘过程包括明确业务目标确定缺失能力定义岗位职责明确汇报关系和上下游确定负责的项目范围描述候选人画像通过 Sourcing 和 Mapping 寻找人才。Sourcing 是找人Mapping 是判断哪些公司、部门和岗位里存在合适的人。例如需要建设广告商业化系统可以重点寻找广告平台、流量交易和金融相关产品人才。需要在复杂组织里开拓新业务大厂加创业经历的人会比较合适他们熟悉复杂协作也经历过探索环境。Agent 领域目前还没有形成特别稳定的产品和技术范式大多数人也缺少完全匹配的项目经验。因此招聘时可以重点观察四个维度。1. 基础素质我常用四个词聪明乐观皮实自省。聪明主要看学习速度乐观看他是否相信这件事值得投入皮实看他经历失败以后是否愿意继续探索自省看他能否持续复盘和成长。2. 专业能力级别高低通常对应负责范围。P5负责功能P6负责模块P7负责产品P8负责产品线P9能够自己创造一块业务。高级别人才需要具备“平地抠饼”的能力可以在方向不清晰、资源不完整的情况下定义目标并推动落地。3. 业务能力候选人需要理解客户是谁行业怎样运转谁在赚钱商业链路如何分配利益哪些需求具有共性哪些需求高度定制产品如何商业化。公司招聘产品和技术人员最终仍然希望他们支持业务目标。4. 组织能力候选人进入组织以后需要和上下游协作。企业会关注他是否能够推动项目、处理冲突、获得资源、管理预期同时避免成为团队里的高风险项。Agent 产品经理和工程师应该怎样准备现阶段完全对口的项目经历比较稀缺。候选人更需要证明自己的学习能力、场景理解和动手能力。这里Agent 产品经理和Agent 工程师需要学习的重点就变了结语写到这里6 次培训的理论板块就结束了如果已经看到这里就一定要清晰我们整体的脉络了。表面上看我们讨论了Agent 框架、架构、Tool、Skill、Pipeline、多 Agent、AI 原生组织和人才要求背后始终围绕着一件事企业怎样让 Agent 长期、稳定地完成有价值的任务。要做好这件事会沿着三条线汇合**架构线**Agent Loop、Harness、Tool、Skill、Context、Memory、任务调度和治理机制共同支撑长期运行**业务线**围绕真实任务设计 Pipeline明确输入、输出、责任人、交付标准和异常处理**组织线**重新划分人与 Agent 的职责调整岗位边界、协作方式、评价体系和人才要求。生产级 Agent 最终会走向一个完整闭环先找到值得解决的业务问题再搭建可以持续交付的系统随后把实践经验沉淀为 Tool、Skill、Pipeline 和评测集最后形成组织可以反复使用的生产能力当然理论框架只能帮助团队少走一些弯路真正做起来具体业务依旧会有很多坑点而这些坑点是真正有价值的部分比如团队为什么决定做 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%免费】