一、最近在面试，发现很多公司都在用ai面试，想试着去做ai面试侧Agent，发现思路上还是有所歧义
-
本来在研究知识库的搭建，突然朋友发了一个问题，主脑单Agent你咋理解的？
-
然后我就说了自己的理解，并且讲了关于调度专家的一个思路。这本身是两个思路，我做了反向的输出做解释。然后讲着讲着我发现自己讲不明白了，有点语无伦次了，有点思路，讲不出来。我说：“这个和通用流程有点像。”讲完就发现没有到点子上。
然后赶紧问了一下豆包，给我讲明白了，这是核心区别：是否有“全局流程编排能力” —— 前者是“主脑+流程化子Agent集群”，后者是“主脑+孤立子Agent集合”，具体差异用3个关键点说清：
- 核心定位：流程中枢 vs. 调用中介
-
主脑单Agent驱动固定流程的多Agent Orchestration（简称“流程编排型”）：主脑不只是“叫人做事”，更像“项目经理”，手里有固定的全局流程模板（比如“先调研→再分析→最后输出报告”），会按流程分配子Agent任务、协调顺序、处理衔接（比如A的输出作为B的输入）。
-
单Agent驱动不同单Agent（简称“简单调用型”）：主脑更像“通讯录”，只负责根据需求“召唤”对应的子Agent（比如要算数据就叫数据Agent，要写文案就叫文案Agent），没有固定流程，子Agent之间是孤立的，不会自动配合。
- 子Agent关系：协作联动 vs. 各自为战
- 流程编排型：子Agent是“流程中的一环”，必须按主脑定的流程协作。比如主脑让“调研Agent”收集用户需求，结果直接传给“分析Agent”做痛点拆解，再传给“文案Agent”写方案，全程是“流水线式联动”。
- 简单调用型：子Agent是“单独的工具人”，各自完成独立任务，互不干涉。比如主脑先叫“数据Agent”算完转化率，再叫“文案Agent”写推广文，但文案Agent不会用到数据Agent的结果（除非主脑单独转发），没有天然联动。
- 适用场景：固定复杂流程 vs. 灵活零散任务
- 流程编排型：适合步骤固定、需要多环节衔接的场景，比如“客户投诉处理”（先接待Agent记录→再售后Agent核实→最后客服Agent反馈）、“产品上线流程”（需求Agent梳理→研发Agent开发→测试Agent验证）。
- 简单调用型：适合需求零散、无需协作的场景，比如“日常办公助手”（查天气叫天气Agent、订机票叫票务Agent、写邮件叫邮件Agent），每个任务都是独立的，不需要按固定顺序来。
简单类比：前者是“工厂生产线”（主脑是生产线调度，子Agent是各工位，按固定流程出成品）；后者是“兼职人才市场”（主脑是雇主，子Agent是不同技能的兼职，随叫随到但不配合做事）。
发现我们做Agent大多数场景都是在用后者用的是更多的是插件调度能力，这本身也是LLM支持的能力，而做ai应用的思路是用流程编排。
思考：这样就突然想明白了一点，可以用混合模式，就是用调度驱动流程（主脑单agent 去驱动不同的固定流程的多agent workflow，实际上这个是做完整了也是一个单Agent）。这样来做就是类似于店铺/租户思维，提供一个总入口，只不过这个店铺自己经营（自己的产品，产品经理思维），而老板需要去开通这个平台，实现客户需求进行一个正确的路由技术（调度能力思维）。所以这里我讲的事儿是加了一层，这一层在想做更多事情的前提下，的确提供了一个入口。但是没有这个调度能力，能不能做这个单一的产品，答案是能做。那在决策上就缺少了这个公司能力的丰富性。所以在这个考量下，我理解还是需要进行一个混合模式去进行开发，只不过多加了一层，系统架构层面上就能够做很多事情啦。
还有一个关键思考点是数据源的开发逻辑：传统流程中，多数程序员的惯性思维是 “等数据传到位再处理”；但在多 Agent 模式下，其实可以让不同 Agent 共享同一个数据源，各自基于这份数据完善并强化自身的单一职能。
- 扣子Agent使用插件进行开发
- 扣子应用直接是使用流程来进行开发
