欢迎关注微信公众号“边界层笔记”，一起交流

---

边界层·应用&Agent｜企业大模型应用的三种形态：搜索问答、协同助手和 Agent 工作流

欢迎回到「边界层」。

我是科里，一个在云厂商做数据与 AI 产品 / 市场 / 策略的打工人。这个号想做的是：给不写代码，但要和 AI 打交道、要做决策的人，一份可以拿回公司内部开会讨论的「技术翻译本」。

在「边界层」里，我习惯用两层视角看问题：

• 边界层内：系统和技术架构到底是什么形态；
• 边界层外：这些技术，落到业务、组织和人的工作方式，会发生什么变化。

这篇文章属于【应用&Agent】栏目，我们就沿着这条线来：

先在“边界层内”把企业大模型应用的三种主流形态讲清楚，再走到“边界层外”，看它们分别对应怎样的数字化阶段，以及未来 12–18 个月可以怎么排期。

---

一、为什么先把“形态”讲清楚？

过去两年，在很多企业里，大模型项目的讨论常常是这样的场景：

• 会上有人说：“我们要做自己的 Copilot，让每个人都有 AI 助手。”
• 也有人说：“先做一个问答机器人，把知识库升级一下，做 MVP。”
• 还有人坚持：“要上 Agent，能自己拆任务、自动跑流程，那才叫 AI 变革。”

问题在于：这些词听起来都对，但每个人脑子里的画面可能完全不一样。

有人说 Copilot，其实想的是“写文档、写代码的助手”；

有人说 Agent，想象的是“能自己决策、自己调用系统的智能体”；

有人说“问答机器人”，只是想先做一个比原来搜索好用一点的入口。

如果一开始没有对齐“我们到底在谈哪一种形态”，后面的所有讨论——从预算、时间表，到 KPI 和组织调整——其实都在不同频道上。技术团队觉得“已经做了很多东西”，业务觉得“体验还好，谈不上颠覆”，管理层则觉得“算不清这笔账值不值”。

所以，在讨论“要不要做 Copilot”“是不是该 All in Agent”之前，有一个更基础的问题其实应该先回答：

在企业里，大模型应用大致能长成哪几种“形态”？

我们现在做的，属于哪一类？预期和形态是不是匹配？

把“形态”讲清楚，本质上是把一张讨论用的地图画出来。

有了这张地图，后面再谈技术选型、ROI、组织变革，才算是站在同一块地面上。

边界层笔记：

这一段的重点只有一句话：如果不先把“我们在做哪一种形态”讲清楚，所有关于 Copilot / Agent / 问答机器人的讨论，都会是各说各话。形态，是对齐预期的起点。

---

二、边界层内：三种形态，一张坐标系

先站在“边界层内”，也就是系统和架构的视角，看看大模型应用可以长出哪几种“样子”。

可以先想象一张简单的坐标系：

• 横轴是系统复杂度 / 集成深度：

  从左侧“几乎只读文档、不改业务系统”，到右侧“深度接入多个核心系统，能真正发起业务操作”。

• 纵轴是业务价值 / 自动化程度：

  从下方“帮你更快看懂信息”，到上方“替你做出决策、推动流程执行”。

在这张图上，三种典型形态大致是这样分布的：

• *搜索问答（Search Q&A）**在左下角。

它接企业的各种文档、知识库、网页，让用户可以直接用自然语言提问，系统去检索相关内容，再由大模型生成一段可读的回答。

从“形态”上看，它是“升级版企业搜索 + 自动摘要”。

• *协同助手（Copilot / 办公助手）**在中间偏上。

它不再是一个独立网站或 App，而是嵌在你每天用的工具里：文档、邮箱、IM、工单系统、CRM、IDE……

它能“看见”你正在做的事，帮你写、帮你改、帮你整理，是一个“常驻在工作现场”的搭档。

• *Agent 工作流（Agent Workflow）**则靠近右上角。

它处理的已经不是单一句“问题”，而是一个业务目标或一条流程：接住一张工单或一个任务，自己查数据、做判断、调用系统，把流程从 A 推到 B。

更像是一个“可执行的自治业务单元”。

这里有两个小提醒：

• 我们是在按“接触业务的方式”来分形态，而不是按行业。

  客服 Agent、法务 Copilot，本质上都是这些形态的组合，只是领域不同。

• “写文案、写 PPT、写代码”这种纯内容生成，不是第四种形态，而是三种形态共同依赖的底层能力。

边界层笔记：

把横轴理解成“要不要深度改系统”，纵轴理解成“要不要替人做决定”，三种形态就很好放：搜索问答负责“看清信息”，协同助手负责“帮你干活”，Agent 工作流负责“让系统自己跑流程”。

---

三、形态一：搜索问答——先让信息“看得见、看得懂”

搜索问答通常是企业接触大模型应用的第一站，也是门槛最低的一类。

从用户视角出发，变化其实非常直观：

过去查东西，要打开知识库、想关键词、点进一堆文档自己翻；现在在一个问答框里，用接近口语的方式问一句——

“我们现在出差报销的标准是多少？”

“客户投诉升级的规则是什么？”

系统直接给你一段整合后的解释，并附上原文出处的链接。

从系统这一侧看，它主要做了三件事：

一是内容治理：

把分散在网盘、Wiki、知识库、网页里的内容收拢、清洗、去重，按权限切好。

二是检索能力：

既能按关键词，也能按语义相关性，找到和问题最相关的那几段内容，而不是简单“全文搜索”。

三是生成回答：

把检索到的内容交给模型，让它生成一段尽量完整、可以直接阅读的答案，并标注引用来源，而不是只丢一堆链接出来。

在数字化转型的大图里，搜索问答对应的是最底层的能力：信息透明。

• 对个人来说，查东西不用再逛遍每个系统、到处问人，时间和心智负担都能减下来；
• 对组织来说，知识不再那么依赖少数“资深老员工”的记忆，而是更容易被普通人访问和理解。

但搜索问答的边界也很清楚：

它主要解决的是“让大家看清楚”，而不是“替大家做决定”。

如果把它当成“AI 转型的全部”，最后一定会失望——日常工作方式其实没有根本变化，只是查资料方便了一点。

边界层笔记：

搜索问答是 AI 时代的“企业知识入口”，是后面所有事情的地基。它值得尽早做好，但更像基础设施，而不是整个转型故事的主角。

---

四、形态二：协同助手——AI 真正进入“工作现场”

协同助手，是很多人第一次真切感受到“AI 改变了我的工作方式”的地方，也是未来 12–18 个月最值得认真投入的一层。

和搜索问答相比，协同助手有两个关键变化：

• 它不再等你“走去问它”，而是一直待在你的工作环境里；
• 它做的不是“答一个问题”，而是帮你做完一件具体任务的一大半。

想象几个具体场景：

• 你在写文档，侧边栏里可以一键让助手“根据现有内容续写下一节”“把这一段改成更正式的表达”“帮我提炼出三个要点”；
• 你在处理客户邮件，助手能读懂整串往来记录，给出一版合适的回复草稿，并提醒你“上次承诺的事项有没有兑现”；
• 你在 CRM 里看某个客户，助手自动帮你把最近的交流、会议纪要、工单历史串成一页“客户近况”；
• 你在处理工单，助手读完用户描述和历史记录，生成一版处理建议和回复，再由你做最后确认。

要支撑这些体验，系统必须具备两类关键能力：

• 上下文感知：随时知道你当前在处理什么——这封邮件、这个文档、这个工单，而不是隔着一个“独立机器人”窗口对话；
• 多工具连接：能在文档系统、邮箱、IM、CRM、工单平台之间拉通信息，并把结果写回原位，而不是只输出一段纯文本给你自己复制。

从个人角度看，协同助手把大量“从 0 到 1 的写作”变成了“从 0.5 到 1 的加工”。会议纪要、周报、客户总结，开始不再从空白页打开，而是从助手给的一版草稿开始，真正需要你花力气的部分，变成“选择、判断、增删”。

从团队层面看，它慢慢会改变的是：

• 大部分会议有没有稳定、结构化的纪要；
• 项目状态对管理者是不是更透明，更容易在第一时间发现异常；
• 新人能不能更快上手，因为他们随时可以请助手帮忙“先写一版”。

当然，协同助手也特别容易做成“功能大合集”：

到处都有一个“AI 按钮”，但没有几个场景是大家愿意每天用的。

更现实的做法，是一开始就明确它是一个“重点场景产品”：

• 先挑两三件你们团队每天都要做、又很耗时间的事：

  比如会议 → 纪要 & 行动项，客户互动 → 回复草稿，项目管理 → 周报和状态总结；

• 把这些场景打磨到“关掉会明显不适应”的程度，让团队先在这里养成依赖；

• 再考虑往更多工具和流程里扩展。

边界层笔记：

协同助手不是“多一个 AI 按钮”，而是在少数高频场景里，变成大家心里默认的“先让我写一版”。只要有 2–3 个这样的场景站住，AI 在团队里的位置就稳了。

---

五、形态三：Agent 工作流——让系统“跑完一条流程”

第三种形态，Agent 工作流，把 AI 从“帮手”推进到了“流程参与者”的角色。

如果用一句话来概括：

你交给它的不再是一个问题，而是一条流程；

它做的不是给你答案，而是沿着流程图，自己查数、做判断、调用系统，把事一步步推进下去。

以客服为例，一个简化过的 Agent 流程可能是这样：

用户提交工单或一段长投诉后，系统先自动判断问题类型和情绪强度，再去知识库和历史工单里找类似案例，给出一个初步解决方案。接着，它会评估这个问题是不是可以自动闭环，如果可以，就直接生成回复并发送；如果不可以，就决定应该分配给哪个小组或负责人，并把整理好的背景信息一起打包给对方。问题解决后，它再把整个处理过程写成结构化记录，用于后续分析和优化。

这个过程里，Agent 做的已经不仅是“看懂文本、写出回复”，而是：

• 在多个系统之间调度：知识库、工单系统、CRM；
• 在每个节点上做“下一步该干嘛”的判断；
• 对整个流程的状态负责。

要让 Agent 工作流真正跑起来，前提条件不少：

• 相关流程要被显式化，有清楚的步骤和分支，而不是“大家默契知道”；
• 涉及到的业务系统要有可用的接口，让 Agent 能在受控范围内读写数据、触发操作；
• 要有完整的日志和审计机制，能追溯“这一决定是谁做的、基于什么信息做的”，否则业务方不会放心放权。

从组织视角看，Agent 工作流触动的是：流程设计、岗位分工、责任边界。

• 哪些环节允许系统先做决策、人来兜底？
• 哪些环节一定要人类做最终判断？
• 一旦自动化出错，责任怎么划分？
• 人的工作，是不是会从“亲自执行每一步”，变成“设定规则 + 处理例外”？

也正因为如此，Agent 工作流更适合作为“一两条关键流程上的深水试点”，而不是一上来就“全公司铺开”的动作。路径上，从“人审机辅”（系统给建议，人执行）到“机审人辅”（系统执行，人抽查），再到极少数场景下的“机审机决”，中间留有足够长的适应期，往往比一口气改完要更现实。

边界层笔记：

Agent 工作流真正在改的是“这条流程谁说了算”。技术成熟只是一部分，流程 owner 是否愿意重画流程、人力和风控是否能接受新的责任边界，才决定这条路能走多远。

---

六、边界层外：从三种形态，到 12–18 个月的路线

回到“边界层外”，也就是业务和组织的视角，再看这三种形态，会发现它们刚好排成一条很自然的路线：

• 搜索问答，对应的是信息透明；
• 协同助手，对应的是人效提升和工作方式改变；
• Agent 工作流，对应的是流程重构和部分自动决策。

如果你负责一个部门、一个 BU，或者公司级的数据与 AI 转型，未来 12–18 个月的行动，其实很容易围绕这三个层次来排。

一个比较现实的拆法是这样的：

0–6 个月：把搜索问答打造成“可信的企业知识入口”

先别追求覆盖所有领域，选 2–3 个大家每天都在问的问题域——比如客服知识库、内部管理制度、IT 支持——把内容治理、问答质量、权限控制做好，让员工愿意用、用得懂、遇到问题第一反应是“先去问问它”。

用使用频次、解决率、用户主观满意度这些朴素指标，来判断这层地基打得稳不稳。

6–12 个月：在协同助手上做出 2–3 个“离不开”的场景

把 AI 深度嵌进会议→纪要、邮件→回复、项目→周报这类高频任务里，

目标不是“多一个按钮”，而是改变默认工作方式——从“从空白页开始写”，变成“先让助手写一版”。

一旦团队习惯了这种节奏，AI 在大家心里的角色就不再是“可有可无的小工具”，而是日常工作流的一部分。

12–18 个月：在一两条流程上试点 Agent 工作流

选流程时，除了看是否规则相对清晰，还要看流程 owner 有没有改造意愿，相关系统接口是否齐备，合规/风控能否接受“先让系统做一部分决定”。

设计时不要一口吃掉，先从“人审机辅”开始，逐渐把一部分低风险环节交给系统自动执行，人来抽查和处理例外。

这既是对技术的考验，更是对组织“愿不愿意重画责任边界”的考验。

边界层笔记：

三种形态既是三种“现在正在发生的样子”，也是未来 12–18 个月可以排成一条路线的三层台阶。与其抽象地喊“要做 Copilot / Agent 转型”，不如先问清楚：我们现在在哪一层，下一步最值得用力的是哪一层。

---

✍️ 科里笔记 Coralyx Notes

Written by 科里（Coralyx），发表于「边界层」

如果你也是不写代码、但想理解 AI 跟上行业发展的人，欢迎关注这个号，一起在边界层上看世界。