生产级Agent 全景：架构、Harness 工程、组织与人才

本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《生产级 Agent 全景：架构、Harness 工程、组织与人才》

上个月我这边非常忙碌，接了个不算轻松的活：为某企业系统性的介绍了什么是生产级 Agent。

懂的同学都会明白，这种面向产研团队的培训是很难做的，好在最后圆满结束，也取得了不错的效果，整个这次培训前前后后进行了 6 场，分别讨论了框架、架构、Skill、Tool、AI 原生组织以及 Agent 人才要求。

这些话题的设计我这边是有深意的，背后其实围绕着同一个问题：

Agent 进入企业之后，究竟应该做什么，又该怎样做成一个可以长期运行的生产系统？

其实现在很多企业都会有这种需求，因为更多的团队已经可以快速做出 Agent Demo，但他们的手法都非常类似：接入一个大模型，配置几个工具，增加知识库，再做一个聊天界面。

可一旦进入生产，很多小问题就出现了，如果没有生产级的经验，往往会摸不着头脑，比如：

1. Agent 应该独立做成一个产品，还是放进原有系统？

   
   

2. 哪些场景适合 Workflow，哪些场景适合 Agent？

   
   

3. Tool、Skill、MCP、知识库分别承担什么职责？

   
   

4. Agent Loop 跑起来以后，还需要补哪些工程能力？

   
   

5. 多 Agent 究竟解决了什么问题？

   
   

6. 企业应该怎样管理一个长期运行的 Agent？

   
   

7. 产品经理和工程师需要具备哪些能力？

   
   

今天，我就把之前 6 次培训偏理论的部分分享给大家，希望对大家有用：

Agent 在企业的定位

理解 Agent，首先要看它和现有软件系统之间的关系。

传统企业软件承担的核心职责，可以概括为 System of Record，记录系统。

CRM 记录客户、线索、订单和合同；ERP 记录库存、采购、销售和财务；项目管理系统记录需求、任务、负责人和进度；飞书文档看起来更加自由，每一行文字依然在记录某类业务事实。

这些软件帮助企业保存信息、管理对象、维护流程，并保证企业拥有一份相对可信的事实记录。

Agent 增加了一个新的软件层：认知与行动层。

用户可以直接提交任务，例如：

帮我分析最近一个月的销售线索，找出高价值客户

生成跟进建议，并把结果更新到 CRM。

Agent 接到任务后，需要完成几件事：

1. 理解用户的意图；

   
   

2. 组织当前任务需要的上下文；

   
   

3. 判断可以使用哪些工具；

   
   

4. 调用不同系统完成操作；

   
   

5. 检查执行结果；

   
   

6. 把最终结果写回业务系统。

   
   

原来需要用户打开多个软件、查找数据、复制信息、执行操作。现在，用户把任务交给 Agent，由 Agent 完成中间过程。

企业软件由此可以分成三层：用户入口与交互层 + 认知与行动层 + 业务记录层。

Agent 的价值主要取决于两个指标：

1. 完成了多少任务；

   
   

2. 完成的任务有多大价值。

   
   

企业最终关心的是交付结果，除此之外的聊天次数、调用工具数量、生成内容长度，都只能算过程指标。

为什么是 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。关键在于知识是否被结构化，模型能否在合适的任务阶段取到需要的信息。

通用复杂任务适合通用 Agent

Deep 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. 它准备做什么？

   
   

2. 它正在调用哪些工具？

   
   

3. 它访问了哪些数据？

   
   

4. 哪些操作已经完成？

   
   

5. 哪些步骤需要人工确认？

   
   

6. 出错以后能不能追踪和恢复？

   
   

因此，产品设计中需要加入以下能力：

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 设计可以先回答两个问题：

1. 用户是否需要长期认识多个角色？

   
   

2. 当前任务是否需要多个执行单元协作？

   
   

第一个问题决定产品形态，第二个问题决定运行架构。

Agent 需要哪些技术层

一个基础 Agent Loop 的代码并不复杂。

用户提交任务，模型判断是否调用工具，运行环境执行工具，再把结果交给模型。循环持续进行，直到模型输出最终答案。

这些东西看起来很简单，但一上生产就完蛋，生产系统需要补齐更多能力。可以将整体架构划分为以下几层：

1. Agent Loop

这是最基础的循环：

用户提出任务

→ Harness 组装上下文

→ 模型进行判断

→ 返回 Tool Call 或最终结果

→ Runtime 执行工具

→ 工具结果交回 Harness

→ Harness 重新组装上下文

→ 模型继续执行

最小版本可以只完成一次 Function Calling。复杂任务需要支持多轮循环、任务终止、异常重试和状态保存。

2. Tool 层

Tool 提供 Agent 可调用的行动能力，包括：

1. 文件读写；

   
   

2. 搜索；

   
   

3. 浏览器操作；

   
   

4. 数据库查询；

   
   

5. 企业系统 API；

   
   

6. 本地命令；

   
   

7. MCP 提供的外部工具；

   
   

8. ...

   
   

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 时发现，大量问题都出现在 Harness：

Tool 描述不清晰；

参数定义模糊；

System Prompt 内部存在冲突；

Skill 触发条件写得不准确；

历史消息污染当前判断；

某个遗留 Hook 阻挡了操作；

工具结果过长，挤占上下文；

权限信息没有及时更新。

模型经常成为第一个被怀疑的对象，可顺着 Trace 检查以后，问题往往集中在上下文装配和执行环境：

调试生产级 Agent，最好先查看完整链路：

模型实际收到了哪些消息？

工具名称和描述是什么？

模型为什么选择这个工具？

Runtime 实际执行了什么？

工具返回了什么内容？

下一轮 Context 如何组装？

哪条规则影响了最终判断？

有了完整 Trace，Agent 才能被持续优化。

Tools

Tool 本身可以理解为一张可调用能力的说明书。它通常包含：

Name；

Description；

Parameters；

返回结果；

错误类型。

模型读取 Tool 的名称、描述和参数，然后判断是否调用。实际执行发生在本地主机、云端 Runtime、浏览器或企业系统里。

例如，用户询问上海天气。

没有天气工具时，模型只能依据已有知识回答，或者明确表示无法获取实时信息。

配置天气工具后，模型会读取工具说明，生成类似下面的调用：

{

"city":"上海"

}

Runtime 查询天气服务，再把温度、天气状态和时间返回给模型。模型根据工具结果生成用户可以理解的答案。

整个过程中，模型负责推理和决策，Runtime 负责执行。

因此，Tool 设计至少要关注四部分：

声明

工具名称和 Description 要准确表达用途。描述模糊会直接影响模型选择。

输入

参数尽量结构化，避免让模型自由拼接复杂文本。必填项、格式和取值范围都需要清楚。

执行

执行环境需要处理权限、超时、失败重试、幂等性和异常。

输出

结果应该方便模型继续判断。大量无关日志、过长文本和混乱字段都会增加模型理解成本。

Tool 数量增加以后，还需要解决工具冲突、相似工具选择、权限隔离和动态加载问题。

正常情况下，一个团队后端隐藏最多的工作就是做各种 Tools 和 CLI 改造，前端工作最多的是构建 Skills 生态：

Skills

Skill 可以看作一种能力组织格式。

一个 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 的区别

概念	解决的问题
Tool	Agent 可以执行什么动作
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 Layer

Pipeline 描述任务怎样在组织里流转。

它需要定义角色、阶段、输入、输出、状态和交付标准。很多传统 SOP 可以在这一层被重新整理。

Skill Layer

Skill 保存组织的做事方法，包括：

专业知识； 操作手册； 判断规则； 分析框架； 代码脚本； 交付模板。

员工经验经过整理以后，可以转化为 Agent 能够调用的能力。

Agent Governance Layer

企业把 Agent 作为持续运行的执行单元进行管理，为它配置身份、权限、日志、审阅和责任边界。

操作系统可以作为组织总线，人持续提供 Context，Agent 按照 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 究竟是怎样长出来的。