夜雨聆风🚀 欢迎来到AI产品经理研习之旅 🚀
本文基于WayToAGI组织的、安克创新渠道 AI 能力建设负责人 Jingxuan 的直播分享《AI建设者：造一套让所有人都能造Agent的系统》整理。
—
他还指出了 AI Builder 和普通用户之间的5个差距：产出能不能直接用，能不能诊断问题，能不能把完整任务交出去，经验能不能沉淀成团队资产，AI 能不能从执行工具变成思考伙伴。
大部分人可能停留在L3或者L4。那么，AI Builder甚至是Architect，具体的表现是怎样的呢？
正巧昨晚在WayToAGI的一场直播中，听到了安克创新渠道 AI 能力建设负责人 Jingxuan 的分享，能够非常好地回答这个问题。与我的认知和实践也高度一致，但她更加完整地讲述了从"定义问题"到"设计数据架构"到"造 Agent 的 Agent"的全过程，特别是关于如何把 AI Agent 融入新品上市这条安克的实际业务运营流程里的落地分享。
以下是我借助AI整理的直播分享内容>>>
需要说明的是：
1.PPT内容我进行了部分的重新整理制作，但不是完美还原，仅供参考
2.过程中穿插了我的一些个人注解或补充，但会明确标识出来
—
阶段一：Prompt Engineering
打开AI或智能体工具，写一段 Prompt：定义角色、指定品类、要求输出清单和对比表。跑一下效果不错，再增加规则（必须包含价格、功能、用户评价等维度）。截图发到群里，同事也觉得挺厉害。
问题很快暴露：换一个品类，输出的维度就不一样了。不同品类要关注的东西不同，甚至分析方法都不同。于是在 Prompt 里不断追加约束——A 品类好了，B 品类又崩了。花了一周调 Prompt，可能比自己手工做一份竞品分析还费时。
阶段二：流程拆分
意识到竞品分析不是一步，而是多步：需求分析 → 确定品类 → 收集数据 → 数据分析 → 生成报告。把这些流程都塞进一个智能体的 Prompt 里，结果 Prompt 越来越长，上下文溢出，前面写的规则后面运行时就遗忘了，幻觉率居高不下。
阶段三：多智能体协作
开始做渐进式披露，把任务拆成多个智能体——一个负责需求分析，一个负责搜索，一个负责分析，一个负责写报告。但跑下来发现：数据一多就容易混乱，一个智能体的产出不能被另一个有效复用，不同阶段的产出质量难以保证。
这三个阶段触及了智能体建设的核心认知跃迁：
阶段转换 | 核心意识 | 踩过的坑 |
|---|---|---|
阶段一→二 | 学会拆流程：认识到复杂任务是多步骤的 | 没有将核心业务逻辑抽象出来，边界未定义清楚，没有接入企业知识，换个品类就崩 |
阶段二→三 | 学会拆智能体、管理上下文：一个智能体做一件事 | 子智能体间的核心数据需求未明确，数据衔接不畅 |
作者注：这三个阶段看似简单，实际上对应了一个重要的认知升级——从"用工具"到"设计系统"。阶段一的问题不在于 Prompt 写得不好，而在于把"结构化的业务判断"塞进了非结构化的自然语言里。阶段二到阶段三的关键跳跃是意识到：Agent 之间需要的不是共享全部上下文，而是定义清晰的交付物。这个认知到了后面的"数据对象设计"会被进一步系统化。
—
安克创新每年大量新品在全球上市，每一款产品的成功上市都需要产研团队和商业化团队的紧密配合。商业化流程（CGTM）涉及：
- 全球策略：市场洞察 → 产品定位 → 全球量价方案
- 区域策略：各区域补齐本地数据 → 本地量价方案
- 渠道策略：各渠道（如亚马逊、线下零售等）各自的量价和操盘方案
- 品牌营销：每个层级都要拉起品牌营销做传播方案
- 此外还有供应链备货、财务商业化论证等角色
这条链有两个天然问题。
痛点一：信息损耗
整条链涉及十多个节点、大几十个商业判断点，全部靠文档和会议传递。每交接一次，上下文就少一层。即使每个节点都做到 99 分，一百多个判断点跌下来，损耗可能超过七成。最终执行层拿到的已经不是全球策略的全貌了。
此外，信息要跨多个角色、跨很长周期传递（如产品档案要从产品端传到全球策略→区域策略→渠道），中间有大量版本需要管理。上游数据变更如果不能同步到下游，整个下游方案可能要推倒重来。
痛点二：经验依赖
链上每个节点的产出质量高度依赖个人经验。做过十次新品上市的全球策略负责人，和刚接手某个区域的新人，产出的操盘方案质量差别巨大。专业人脑中装着历史定价的教训、渠道踩过的坑，但这些经验没有被沉淀下来。每次新品上市，每个人都要从零开始判断。
目标
基于以上痛点，安克希望构建新品上市流程智能体，实现：
- 每个商业判断都有结构化载体存在，完整流转到下一个节点（不再依赖人脑记忆、会议传话、线上文档）
- 每个核心输出都有校验机制（未通过校验不流入下游），数据源头更新后，所有依赖节点自动同步
- 每次新品上市的经验沉淀在系统中，可持续调用
作者注：信息损耗可以做一个简化的量化推演。假设整条链有 15 个关键节点，每个节点在传递信息时的保真度为 95%（已经是相当高的水平），那么经过全链传递后，信息保留率约为 0.95^15 ≈ 46%。如果节点间保真度降到 90%，保留率只剩 0.9^15 ≈ 21%。这还只是信息的"量"的损耗，没有算"质"的扭曲——每次传递中理解的偏差会放大。所以 Jingxuan 说的"损耗超过七成"并不夸张。这也解释了为什么"定义数据对象"是整个方法论的第一优先级——先把信息的保真传递解决掉，再谈智能化。
—
Step 1：定义问题
在开始设计任何智能体之前，先回答两个问题：
1. 客户是谁？
客户不是流程中的某一个角色，而是流程中的每一个角色。因为要实现的是全流程提效。如果只针对某个角色优化，其他角色还是拿不到上下文，最后还是靠开会传话，整条流程没有被接管。
2. 要创造什么价值？
分析后发现，流程智能体提供的价值分两层：
价值层级 | 核心目标 | 实现方式 |
|---|---|---|
第一层：解决信息损耗 | 确保每个环节的核心数据被统一收集、存储，能被应有环节调取和更新，实现全流程上下文共享 | 定义好每个环节要产出的核心数据，统一存储，让信息可流转 |
第二层：解决经验依赖 | 让 AI 在关键判断节点辅助业务思考，自动获取和生成数据，减少对个人经验的依赖 | 投入更多智能体调优，让 AI 真正辅助决策 |
为什么分层很重要？如果不先解决第一层（信息损耗），直接冲第二层（经验替代），会发现要产出的智能体非常多，每个都需要大量调优。而第一层不要求每个智能体都调优到百分百自运行——人可以在里面有更多参与。
分阶段目标：
- 先解决信息损耗（定义清楚有哪些信息需要被获取、存储、传递、共享上下文）
- 再解决经验依赖
Jingxuan 特别强调：内外部洞察不是某个阶段的任务，而是贯穿整个搭建过程的工作习惯。 从定义问题到流程梳理、搭建智能体、业务迭代，都需要持续做内外部洞察。
作者注：这个"两层价值模型"是我认为这场分享中最有实操价值的框架。很多企业做 Agent 落地失败，根因就是跳过了第一层直接冲第二层——在信息流转机制都没建立的情况下，让 AI 做决策辅助，结果发现数据质量不够、上下文不完整、智能体频繁出错。安克的经验表明，第一层（定义数据对象 + 存储设计 + 流程对接）完成后，信息损耗的问题就已经能大幅改善。这不需要 AI 能力有多强，需要的是业务架构能力。
Step 2：定义业务流程和数据模板
目标：解决信息断层和共享上下文的问题。
具体做两件事，且两者需要相互印证：
- 梳理业务流程：基于实际业务流程，思考如果有 AI 加入，最优的流程定义是什么
- 定义数据对象：看每个流程环节有没有有价值的数据对象产出
最终产出：核心的业务数据对象 + 对应的关键活动节点
以新品上市流程为例，梳理出的核心流程智能体包括：
流程智能体 | 核心输出数据对象 |
|---|---|
洞察构建 | 洞察条目（大盘/竞争/竞品/自身/用户多维度）+ 洞见条目（可执行的建议） |
产品定位 | 产品定位数据模板（含用户画像、目标人群等子章节） |
全球量价 | 全球量价方案数据对象 |
本地量价 | 各区域本地量价方案 |
渠道量价 | 各渠道量价方案 |
营销方案 | 传播方案数据对象 |
同时定义关键检查点：
- 量价方案在三个层级（全球/区域/渠道）的多阶段互锁
- 商业结果的收益分析
- 最终全球操盘方案的可行性验证
关于"互锁"：量价方案需要在三个层级之间对齐——渠道量价和本地先做一层互锁，完成后所有市场再跟全球做一套互锁。确保三个层级的数据相互可见、逻辑一致。
关键设计决策：智能体间的连接方式
不同 Agent 之间的交互和连接，是通过定义好的核心数据对象来进行的，而非传递完整上下文。例如，洞察构建完成后输出核心数据对象（洞察和洞见），后续所有智能体只需要消费这个输出即可——不需要知道洞察构建过程中的其他上下文。
这也是回答弹幕提问"Agent 之间的 context 怎么控制？特别是几百轮对话后"的核心答案：用输出交付物来做 Agent 间的连接和信息传递。
作者注：以"洞察构建"智能体为例，它的核心数据对象可以简化为：
- Meta：品类、市场、时间范围、生成日期- 洞察条目（多条）：维度（如竞品定价、用户评价）、数据源（如 Amazon 爬虫、VOC 数据库）、关键发现、置信度（高/中/低）- 洞见条目（多条）：来源洞察（回溯到具体洞察条目 ID）、建议动作、影响范围（全球策略/区域策略/渠道）- 校验状态：通过/未通过 + 校验规则 ID
关键设计要点：每条洞察都有"数据源"和"置信度"标注，确保下游消费者知道信息的可靠性；每条洞见都回溯到具体洞察条目，保证建议有据可查；整个对象有一个"校验状态"，未通过校验的数据不会流入下游。这就是 Jingxuan 说的"用输出交付物做 Agent 间的连接"。
数据对象的存储设计
定义好数据对象后，还需要进一步设计存储方案：
- 将抽象的数据对象与数据实体绑定（数据存在哪里？从哪里来？怎么取？）
- 设计好每个字段的类型、谁来写入、谁来读取
- 明确哪些数据已在系统中可用、哪些需要专门建设
- 存储形式不固定（可以是公司数据库、本地文件夹等），但必须提前想清楚
作者注：数据对象在 Agent 间的角色，类似软件工程中的"接口"（Interface）。一个定义良好的接口，让上下游组件可以独立开发、独立迭代，只要接口契约不变，内部实现怎么改都不影响对方。Agent 之间也是同理——如果"洞察构建"的数据对象定义清楚了，负责"产品定位"的 Agent 不需要知道洞察是怎么构建的，只需要按约定格式读取数据。这是一种松耦合的设计思想，和企业软件架构中的模块化设计一脉相承。区别在于，传统软件接口传递的是结构化数据，而 Agent 间传递的是"带有业务语义的结构化数据"。
Step 3：构建流程智能体
在 Step 2 的基础上，进入第二层价值的实现——让智能体在关键判断节点真正辅助业务思考。这需要三样东西：
1. 业务 Know-How 的梳理与规则化
以"洞察构建"中的竞品洞察模块为例，看似简单，实际涉及两个专门流程：从哪里获取洞察 → 如何从洞察转化为洞见。
很多隐性经验必须转化为规则，智能体才能稳定执行：
- 不同电商平台的促销周期不同，直接录入模板可能导致定价判断出错
- 过去一段时间的数据如果不标注日期，趋势分析会失真
- 某些竞品判断只在产品定位环节由负责人做，市场洞察环节只记录客观事实
这些经验散落在团队成员脑中，需要跟业务负责人讨论才能完整梳理出来。每条经验都要转化为智能体可执行的具体指令，确保数据模板产出稳定结果、下游数据不被污染。
2. 数据建设
- 结构化数据：历史销售数据等已有数据仓库中的数据，需要拉取或重新开发验证
- 非结构化数据：用户洞察、VOC（Voice of Customer，用户声音）等，需要收集、结构化存储到数据库中，让智能体可以直接查询
3. 工具开发
每个自动化流程背后都有工具驱动：
- 数据库查询工具（从数据仓库拉数据）
- 文档读取工具
- 需要专门开发的工具
规则、数据、工具——三样都备齐了，数据模板的产出和流转才有质量保障。规则写得再清楚、数据配得再齐，如果工具效果不好，节点也跑不起来。
作者注：Know-How 显性化是整个过程中最难的一步，也是真正的组织认知天花板。原因有三：第一，业务专家自己往往说不清自己"知道"什么——很多判断是模式识别式的直觉，不是可以用语言表达的规则。要把这种隐性知识转化为显性规则，需要反复的"出题-验证"循环。第二，即使梳理出来了，规则之间可能有矛盾——不同场景下的"最佳实践"可能是互相冲突的。第三，业务在变，规则也在变。上季度有效的定价策略，这个季度可能因为竞品动作就不适用了。所以"规则化"不是一次性工程，而是一个需要持续维护的活资产。这也解释了为什么后面的"自迭代机制"如此重要。
子智能体的嵌套设计
全流程智能体的每个子流程智能体（如洞察构建），也需要走一遍完整的搭建路径：定义问题 → 梳理业务流程 → 定义数据模板和存储方式 → 构建智能体。
颗粒度不同，但范式相同。最终通过 Prompt 和代码将这些层串联起来，构成完整的流程智能体。
Step 4：迭代优化
智能体上线后会持续面临变化：
- 公司业务流程变化
- 市场情况变化
- 模型能力本身变化（几个月前定义的业务规则可能本季度就变了）
- 之前为弥补模型缺陷搭建的脚手架，现在可能不再需要
为此，安克设计了一套自迭代流程：
质量飞轮：通过用户使用 → 收集反馈（主动 VOC + 被动信号提取）→ 找到优化方案 → 验证改进，让智能体持续变好。
作者注：这里的"信号采集"设计有一个容易被忽略的细节：它不是上线后才开始的，而是在设计智能体的时候就要规划好"采集什么信号"。比如，洞察构建智能体上线时，就应该同时埋点记录：用户在哪些环节做了手动修改、哪些洞见被直接采纳、哪些被拒绝及拒绝原因。这些信号就是后续迭代的燃料。另一个容易被低估的成本是：维护这套迭代机制本身需要持续投入。信号分析、根因定位、方案制定——这些都不是自动完成的，需要有专人（或专门的能力建设团队）持续跟进。所以 Agent 系统的真实成本不只是"搭建"，还有"持续运维"。
通过实践，安克总结出构建流程智能体需要三类核心能力：
现实挑战：这三种能力很难集中在一个人身上，即使是一个团队也不容易凑齐。对于有大量复杂业务流程的企业来说，人才密度不足以支撑所有流程的智能化。
作者注：三类能力里，"业务架构师"是最稀缺的，也是最难招的。技术实现可以通过招聘和外包解决，效果检验可以通过流程和工具辅助，但"从复杂业务中抽象出核心流程和数据对象"这项能力，需要对业务有深度理解、同时有系统设计思维的人。这类人通常已经在业务线上承担重要角色。
—
更进一步，安克在想：搭建流程智能体本身就是一个多决策、多流程的任务——它为什么不能也是一个流程智能体？
于是，按照相同的范式来设计。
首先定义问题：
- 客户：企业各业务线中最懂流程的专家（COE、流程负责人、业务负责人）。系统里做不了的是他们脑中的业务 Know-How，AI 需要他们给出独特输入。
- 痛点：能力门槛太高、没有标准路径、产出质量无保障
具体实现
按照相同的四步法（定义问题→流程数据模板→智能体构建→迭代优化），将"产出流程智能体"本身拆成子环节：
子环节 | 功能 |
|---|---|
需求澄清 | 澄清要构建的智能体的目标和范围 |
数据对象设计 | 设计智能体要产出和消费的数据对象 |
业务流程设计 | 设计智能体要驱动的业务流程 |
智能体详细设计与试跑 | 详细设计智能体并试跑验证 |
发布与自迭代 | 上线后进入自迭代优化循环 |
两个核心伴随机制
1. 洞察构建：打通企业内部知识库（飞书、数据库、工具库），在"造 Agent"的每个环节都能充分进行内外部洞察。
2. 引导共创：这个"造 Agent 的 Agent"对用户来说不是单纯的执行者，而是共创者——用户在每个环节都感觉有一个与自己水平齐平（甚至更高）的人在引导、碰撞，最终找到全局最优解。
安克内部已有这样的产品，并且已经试跑了一段时间。
作者注："引导共创"这个概念值得多说两句。它不是传统的"向导式问答"——那种模式是系统问、用户答，本质上还是填表。真正的共创是：用户提出一个模糊的意图，系统不是直接执行，而是先帮用户厘清意图本身。比如用户说"我想造一个竞品分析 Agent"，共创型的系统会先问：你分析的竞品维度是什么？分析的频率是什么？产出给谁看？上游数据从哪来？这些问题不是预设的清单，而是基于对"竞品分析"这个领域的理解，动态生成的。它要求系统自身对"如何搭建 Agent"这件事有足够的元认知。这可能是整个分享中最有前瞻性的设计，也是最难实现的部分。
—
回顾整场分享，Jingxuan 总结了七条核心判断：
- 先定义问题，再动手造。 不要急于设计智能体，先想清楚客户是谁、要创造什么价值、分几步走
- 两层价值要分步兑现。 先解决信息损耗（定义好数据和流程），再解决经验依赖（让 AI 真正辅助思考）
- Agent 间靠数据对象连接，不靠完整上下文。 每个智能体只消费上游定义好的输出交付物
- 业务 Know-How 是灵魂。 规则、数据、工具三样都齐了，智能体才有质量保障
- 上线是起点，不是终点。 设计自迭代的信号采集和反馈闭环，让质量飞轮转起来
- 用智能体造智能体。 当搭建流程本身也被抽象为流程智能体时，企业才能真正规模化
- 降低门槛的关键是"引导共创"。 不是让业务人员学会技术，而是让系统像一个高水平的伙伴一样引导他们
而我印象深刻并再次思考的是：
1. 先拆解流程和动作，再考虑如何进行AI化设计。 两层价值模型的务实之处在于：不急着让 AI 做决策，先把信息的"管道"建好。管道通了，水泵才有意义。这个顺序不能反。
2. 人的 Know-How 是真正的瓶颈，不是模型。 模型能力在快速进化，但业务经验显性化这件事，进展慢得多。安克花大量时间做的"规则梳理"，本质上是在解决组织认知的外化问题。我把它叫做“知识工程”。这件事没有捷径。
3. 规模化的关键不是降低技术门槛，而是改变工作方式。 "造 Agent 的 Agent"不是让业务人员学会写 Prompt，而是让系统像一个高水平顾问一样引导他们。这是从"工具赋能"到"系统引导"的范式转变。
如果（1）你也正在尝试成为一个AI Builder（2）你的企业也在尝试 Agent 落地
这场分享应该给出了很好的参考答案（尽管jingxuan没有办法在直播分享中透露更多具体的细节）。
本文基于公开直播分享整理增强。原文观点归分享者所有，「作者注」部分为基于个人认知和实践的合理推断，不代表分享者本人立场。
更多相关历史文章，参见：
[长长长文预警]从4A架构视角看AI原生应用的底层逻辑：企业如何打造真正有用的AI Agent？
参考资料：
通往AGI之路：《AI建设者:搭建多Agent架构》直播
课代表立正：《AI User 与 AI Builder 的 5 个差距，和背后具体技术原因 | 科技大厂打工人版》
课代表立正：《2026年，AI胜任力模型：从聊天党到架构师》
