【综合实战】实战:AI Agent 编排办公流水线

摘要:用 AI Agent 框架把多个 Agent 串成一条自动跑的办公流水线,周报场景一次跑通。

你需要先知道几个术语

本文是系列里的"硬核综合实战",第一次出现的术语都先用大白话翻译一遍,后面就当共识用了:

• AI Agent(智能体)= 能自主感知、规划、执行多步任务的 AI 助手。跟普通 GPT 的区别是,它不仅能"答你一句话",还能自己决定"下一步该干嘛、调用哪个工具、做完再回报"。
• MCP(Model Context Protocol,模型上下文协议)= Anthropic 牵头开源的标准化协议,专门用来让 Agent 调用外部工具/数据源。简单说:以前 Agent 想调数据库、读文件、调 API,要为每个工具单独写适配代码;有了 MCP,工具只要"挂"上 MCP 接口就能即插即用。⚠️ 各大框架对 MCP 的支持进度不一样,文末会单独标注。
• Coze / 扣子= 字节跳动的 AI Agent 平台(coze.com 海外版、扣子/coze.cn 国内版)。零代码搭 Bot,内置工作流、插件、知识库、多 Agent 协作,国内用户首选。
• Dify= 开源 LLM 应用平台,支持 Agent、工作流、知识库,可自托管,技术同学常用。
• n8n= 开源工作流自动化(类似 Zapier 但更强)。AI Agent 节点 2024-05 起;正式 MCP 节点(Server Trigger + Client Tool)是 v1.88.0(2025-04-10)上线,2024 时点 MCP 还是实验性,可以和 LLM、HTTP、数据库等几十种服务对接。
• Power Automate / Copilot Studio= 微软系。Power Automate 管流程,AI Builder 出 AI 能力;Copilot Studio 可以定制企业级 Copilot Agent,深度绑定 Microsoft 365。
• 工作流(Workflow) vs 多 Agent 协作(Multi-Agent)= 工作流是"画好一条流水线,数据按节点跑",每一步干什么是写死的;多 Agent 协作是"招几个专精 Agent,让主 Agent 调度",灵活但容易跑偏。两者各有适用场景,本文会对比。
• 插件 / 工具(Plugin/Tool)= Agent 能调用的外部能力,比如"发邮件插件""SQL 查询插件""飞书消息插件"。Agent 之所以能"动手",全靠工具。
• 编排(Orchestration)= 把多个 Agent/工具/工作流按一定顺序串起来,让它们像一个团队一样配合干活。编排 ≠ 随便堆功能,是有"主控 - 分工 - 协同"的层次感。

一、痛点引入

你肯定有过这种周五下午:

1. 打开邮箱,翻过去 7 天的邮件,挑出"客户反馈 / 项目进展 / 风险点",手动复制粘贴到周报草稿;
2. 打开 BI 平台,导出本周销售数据、新增客户、转化率,做张表,生成图;
3. 打开 Word,把上面的内容拼起来,调一下格式,发邮件给老板;
4. 中途被一句"这张图能再细一点吗 / 这个数据再核一下"打回,从头再来。

整一套下来,3–4 小时没了。但真正需要"思考"的部分(总结、洞察、提建议)其实只占 20%,剩下 80% 都是"重复搬数据"。

这就是 AI Agent 流水线要解决的问题:让 80% 的搬数据活儿自动跑,你只管最后 20% 的判断。

更进一步:很多公司已经在用 GPT/Gemini,实际感受是"聊得挺爽,但让它干一连串真实任务就抓瞎——因为单个 Chatbot 只能"一问一答",没法串多步、没法真去发邮件/查库/写文件/推飞书消息"。

所以本文要干的不是"再介绍一个 Chatbot",而是真的把多个 AI Agent 串起来,搭一条自动跑的办公流水线——以周报场景为例,带你从 0 到 1 跑通。

二、目标产出

学完这篇,咱们能搞定这几件事:

• 理解 AI Agent 跟普通 Chatbot 的本质区别,知道它什么时候有用、什么时候是噱头;
• 在 Coze / 扣子上搭一条 3 Agent 协作的周报流水线(邮件 Agent + 数据查询 Agent + 报表生成 Agent),30 分钟跑通最小可用版;
• 拿到 3 套可直接复制的提示词(邮件摘要 / 数据洞察 / 周报生成)+ 工具调用配置;
• 看清 Coze / Dify / n8n / Power Automate / Copilot Studio 五大平台的编排差异,知道自己的企业该用哪个;
• 看懂 MCP 协议到底解决了什么,避免被厂商话术忽悠。

下面全程给真实可落地的搭建步骤,所有提示词拷过去就能用。

三、案例实战

准备:选平台与场景

为什么选 Coze / 扣子作为主案例?

• 国内访问快,中文提示词支持好;
• 个人免费版每日送 500 资源点/账号(每日重置,不可增购);个人进阶版 9.9 元/月,30,000 资源点/月,本案例免费版够用;
• 多 Agent 模式 + 工作流模式都有,可以对比看;
• 内置插件丰富(飞书、邮件、数据库、API 等);
• 视觉化拖拽,边搭边看。

对比场景:同一个周报流水线,我会告诉你它在 Dify / n8n / Power Automate 上分别怎么搭,差异在哪。

先确认你要的业务场景(本文选最常见的"自动周报"):

每周五 17:00,自动收集本周邮件关键事项 → 自动查 BI 数据库拿本周数据 → 自动汇总成 Markdown 周报 → 推送飞书 / 邮件给老板。

涉及 3 个 Agent:

Agent	职责	关键工具
邮件 Agent	拉过去 7 天的邮件,过滤掉无关邮件,提取关键事项	扣子官方通用 SMTP/IMAP 集成(一次配账号),社区版可选 Gmail / QQ 邮箱助手等细分插件
数据查询 Agent	按本周日期区间查销售/客户数据,做初步汇总	HTTP 节点调 BI API / 自建数据库插件(扣子无通用 SQL 插件;内置数据库仅 PostgreSQL)
报表生成 Agent	把邮件事项 + 数据汇总成 Markdown 周报草稿	LLM(写作模型) + 飞书消息插件

外加一个主控 Agent / 工作流,负责"调度"。

---

步骤 1:注册与基础环境

1. 打开 扣子(coze.cn) (国内版),用手机号注册;海外用户用 coze.com;
2. 进入"工作空间",点"创建 Bot",选"多 Agent 模式"(**注意:**不是"单 Agent",多 Agent 模式才有"调度 + 子 Agent"的层次);
3. 命名:周报助手,描述:每周自动汇总邮件 + 数据 + 生成周报。

💡 关键点:扣子有"单 Agent 模式"和"多 Agent 模式",多 Agent 模式才是本文要用的。单 Agent 也能调用工具,但它是"一个 Agent 干所有事";多 Agent 是"主 Agent 调度 + 多个子 Agent 分工",扩展性强得多。

步骤 2:搭建"邮件 Agent"——子 Agent 1

目标: 让 Agent 自动拉过去 7 天的邮件,过滤掉通知/广告,提取关键事项。

2.1 创建子 Agent

在"多 Agent"编排画布里,添加子 Agent → 命名为"邮件摘要 Agent"。

2.2 配置提示词(Persona & Task)

子 Agent 的提示词分两块:人设(Persona) + 任务指令(Task)。

text
# 人设(Persona)
你是一位资深行政助理,擅长从大量邮件中提取关键事项,过滤掉无关噪音。

# 任务(Task)
1. 调用「邮件查询插件」,拉取过去 7 天(日期窗口由工作流「获取今天的日期」节点 + `date.subtract(N,'day').format('YYYY-MM-DD')` 算出)的所有邮件;
2. 过滤规则:剔除「自动通知/广告/订阅邮件/内部周会纪要抄送」,保留:
   - 客户反馈类(咨询、投诉、表扬)
   - 合作方沟通类(报价、合同、技术对接)
   - 内部重要事项类(审批、决策、风险预警)
3. 按时间倒序,提炼每封邮件的「主题 + 一句话摘要 + 关键行动项(谁、何时、做什么)」;
4. 输出 Markdown 表格,字段:日期 / 发件人 / 主题 / 摘要 / 行动项。

# 输出格式(Output Format)
仅返回 Markdown 表格,不要任何解释性文字。

# 边界(Boundary)
- 不要伪造邮件内容,如果某天没邮件,直接写"无";
- 不要输出完整邮件正文,只摘要。

2.3 添加工具

在子 Agent 的"插件"区域,搜索并添加:

• 邮件相关插件:扣子官方提供的是通用 SMTP/IMAP 集成(一次配账号即可收发),社区市场里另有 Gmail / QQ 邮箱助手等细分插件,按你公司邮箱自选;
• 如果你的邮箱没有现成插件,用「HTTP 请求」插件,自己接邮箱 API(企业微信邮箱、阿里邮箱都有 REST API);
• 日期工具:在工作流里加一个「获取今天的日期」节点(或导入社区插件 yesterday_date),把日期作为变量注入 Agent。⚠️ 扣子 Bot 提示词中没有 {{yesterday}} 这种日期"内置变量",{{}} 占位的内容必须先在工作流节点或 Bot"变量"里定义。

⚠️ 重要:权限最小化——给邮件插件的 token 只授"读取"权限,绝对不要授"删除/发送"权限。Agent 跑偏了也最多只读不写。这是 Agent 落地的铁律之一。

步骤 3:搭建"数据查询 Agent"——子 Agent 2

目标: 查 BI / 数据库,拿本周销售数据,做初步汇总。

3.1 创建子 Agent

再添加一个子 Agent,命名"数据查询 Agent"。

3.2 配置提示词

text
# 人设(Persona)
你是一位数据分析师,擅长用 SQL / API 拉数并做初步汇总。

# 任务(Task)
1. 调用「数据库插件」或「HTTP 节点」,数据库连接信息见变量 {{DB_CONN}}(由工作流前置节点定义、注入);
2. 查询本周(`{{week_start}}` 到 `{{week_end}}`)的数据,SQL 模板见下方;两个日期都来自工作流「获取今天的日期」+ `start_of_week` / `end_of_week` 节点的输出;
3. 返回:本周销售额 / 新增客户数 / 转化率 / Top 5 客户 / 异常订单(金额超过 10 万);
4. 如果查询失败,把错误信息原样返回,不要编数据。

# SQL 模板(可按你的业务表替换)
SELECT
  SUM(amount) AS week_sales,
  COUNT(DISTINCT customer_id) AS new_customers,
  AVG(conversion_rate) AS avg_conversion
FROM sales_dashboard
WHERE date BETWEEN '{{week_start}}' AND '{{week_end}}';
  -- {{week_start}} / {{week_end}} 由工作流节点注入,不是 Bot 内置变量

# 输出格式(Output Format)
仅返回 JSON,字段固定:
{
  "period": "{{week_start}} ~ {{week_end}}",
  -- 上面两个 {{}} 由工作流节点提前定义、注入
  "week_sales": 数字,
  "new_customers": 数字,
  "avg_conversion": 数字,
  "top5_customers": [{"name":"...","amount":数字}],
  "anomalies": [{"order_id":"...","amount":数字,"reason":"..."}]
}

# 边界(Boundary)
- 绝不执行 INSERT/UPDATE/DELETE,只 SELECT;
- 查不到就返回空数组,不要瞎编。

3.3 添加工具与"防爆"机制

• 数据库插件:扣子无通用 SQL 插件;外部数据库建议走 HTTP 节点调 BI 查询 API(Metabase、Tableau、Quick BI、神策都有查询接口),或者在插件市场自己建一个数据库插件(扣子内置数据库仅 PostgreSQL)。无论哪种,数据库连接串({{DB_CONN}})必须先在工作流节点里定义、注入到子 Agent —— 不能写成"扣子内置变量";
• HTTP 插件:如果你的数据在 BI 平台,用 HTTP 调它们的查询 API;
• 在扣子的"代码节点"或"前置检查"里加一句:IF SQL 含 INSERT|UPDATE|DELETE|ALTER|DROP THEN REJECT——给 Agent 上"安全锁"。

💡 关键点:Agent 跑 SQL 是最容易出事的地方。生产环境一定要用"只读账号 + 模板 SQL + 关键字黑名单"三层防护,缺一不可。

步骤 4:搭建"报表生成 Agent"——子 Agent 3

目标: 拿前两个 Agent 的输出,生成 Markdown 周报。

4.1 创建子 Agent

添加第三个子 Agent,命名"周报生成 Agent"。注意:这个 Agent 不需要外部工具,只用 LLM 写作。

4.2 配置提示词

text
# 人设(Persona)
你是一位资深项目经理,擅长把零散信息整理成清晰的周报。

# 输入(Input)
你会收到两份上游 Agent 的输出(均由主 Agent / 工作流节点的"全局变量"回填):
- {{input.email_summary}}:邮件 Agent 返回的 Markdown 表格
- {{input.data_summary}}:数据 Agent 返回的 JSON

# 任务(Task)
1. 阅读两份输入,提炼本周的「关键进展 / 数据亮点 / 风险与问题 / 下周计划」;
2. 按以下 Markdown 模板输出周报:

# {{input.week_label}} 周报

## 一、本周关键进展
- (从 {{input.email_summary}} 中提炼 3–5 条)

## 二、数据亮点
- 销售额:{{input.data_summary.week_sales}}
- 新增客户:{{input.data_summary.new_customers}}
- 转化率:{{input.data_summary.avg_conversion}}%
- Top 客户:...(列 Top 3)

## 三、风险与问题
- (从 {{input.email_summary}} 标注"风险/异常"的邮件 + 数据异常中提炼)

## 四、下周计划
- (基于本周未完成 + 客户待办,推测 3 条)

# 边界(Boundary)
- 所有数据必须来自输入,绝不编造;
- 数字保留 2 位小数;
- 字数控制在 800 字以内。

4.3 不需要外部工具

这个 Agent 是"纯写作型",不要给它数据库/邮件工具——少给工具,Agent 越稳定。

⚠️ 变量前置定义提示:提示词里的 {{input.week_label}} / {{input.email_summary}} / {{input.data_summary}} 都是用户自定义变量,必须先在 Bot 的"变量"里声明,或由主 Agent / 工作流节点的"全局变量"回填 —— 扣子 Bot 提示词没有"写了 {{}} 就能即取即用"的内置变量机制。

步骤 5:主控 Agent / 工作流编排

这是最关键的一步——把 3 个子 Agent 串成流水线。

方案 A:多 Agent 模式(扣子原生,适合"路由分发",不适合严格串行调度)

⚠️ 关键澄清:扣子"多 Agent 模式"的本质是路由分发,不是主 Agent 用自然语言"串行调度"子 Agent。主 Agent 不能像聊天一样说"先调 A、再调 B、拿到结果再调 C";它只能通过 「全局跳转」节点 + 结构化 target/context JSON 来选路由。严格串行(邮件→数据→周报→飞书)请用方案 B 工作流。

主 Agent 的提示词只描述"什么时候选谁",真正选路由靠「全局跳转」节点或子 Agent 节点的配置:

text
你是周报助手的主控 Agent。规则(只负责路由,不负责编排):

- 用户输入含「邮件 / 收件箱 / inbox」关键字 → 路由到 [邮件摘要 Agent];
- 用户输入含「数据 / 销售 / BI」关键字 → 路由到 [数据查询 Agent];
- 用户输入含「生周报 / 周报 / 总结」关键字 → 路由到 [周报生成 Agent];
- 其它场景 → 自己回答。

# 「全局跳转」节点的输出范本(结构化 JSON,不是自然语言)
{
  "target": "email_agent | data_agent | report_agent | self",
  "context": {
    "date": "{{date.format('YYYY-MM-DD')}}",                  // 工作流节点算好的日期
    "yesterday": "{{date.subtract(1,'day').format('YYYY-MM-DD')}}",
    "week_start": "{{date.start_of_week.format('YYYY-MM-DD')}}",
    "week_end":   "{{date.end_of_week.format('YYYY-MM-DD')}}"
  }
}

真实约束(踩过的坑):

• 多个子 Agent 之间不能直接传递结构化变量;只能靠"全局变量"或工作流把上游结果回填到下游;
• 主 Agent 拿不到上游 Agent 的中间结果,也没法保证按固定顺序依次调;
• 因此"严格串行调度"用本模式很别扭——本文这种"邮件→数据→周报→飞书"的串行链路,不适合走方案 A。

触发方式:扣子里可以配"定时触发"(每周五 17:00)或"Webhook 触发"(外部系统调)。

方案 B:工作流模式(严格串行调度的正解)

如果 3 个 Agent 的依赖关系明确,严格串行调度请用工作流模式,按节点画出来:

[开始:定时触发]
   ↓
[邮件摘要 Agent 节点]
   ↓
[判断节点:邮件是否成功?]
   ↓ 是              ↓ 否
[数据查询 Agent 节点] [发邮件报警给管理员]
   ↓
[判断节点:数据是否成功?]
   ↓ 是              ↓ 否
[周报生成 Agent 节点] [发邮件报警给管理员]
   ↓
[飞书消息集成(基于飞书机器人 Webhook):发送周报]
   ↓
[结束]

工作流模式的优点是:每一步都有显式的成功/失败分支,Agent 跑偏了能立刻告警,且能严格按"邮件→数据→周报→飞书"串行执行。多 Agent 模式适合"路由分发"——用户说一句话,主 Agent 选一个子 Agent 来响应;不适合严格串行调度。

⚠️ 飞书消息集成的接入前提:扣子的「飞书消息」集成底层走的是飞书自定义机器人 Webhook,你必须先在飞书侧打开目标群 →「群设置」→「群机器人」→「添加机器人」→「自定义机器人」,拿到 Webhook URL,再回到扣子集成页粘进去;企业旗舰版还要组织管理员先开"外部集成"开关,否则保存会失败。

💡 实战建议:严格串行场景直接用工作流;只有"一句话分派给不同子 Agent"的路由场景才用多 Agent 模式。不要试图让多 Agent 模式"用自然语言串行调度子 Agent"——它做不到稳定按顺序执行,中途任一环节出错,主 Agent 没有可靠的"下一步"机制。

步骤 6:测试与试跑

1. 在扣子的"预览调试"区,手动输入"生成周报",看 3 个 Agent 是否按顺序触发;
2. 先用测试数据 / mock 数据跑通,别一上来就接真实邮箱和数据库;
3. 看每一步的"运行日志",扣子会显示每个 Agent 的输入输出;
4. 故意制造失败:把邮件插件 token 故意填错,看错误能不能被"判断节点"捕获并报警;
5. 通过后,在"发布"里把定时触发设上(每周五 17:00)。

步骤 7:小步上线

别一上来就接老板的邮箱和真实数据库。推广顺序:

1. 第 1 周:自己用,生成"自己的周报",把结果存草稿,人工改后再发;
2. 第 2 周:给自己 + 直属上司用,把草稿改成"半自动";
3. 第 3 周:给团队用,接飞书群;
4. 第 4 周:接老板,完全自动。

每一步都留"人工把关"环节,Agent 出错能立刻发现。

---

附:五大平台横向对照

平台	适合谁	编排方式	多 Agent 能力	MCP 支持	学习成本
Coze / 扣子	国内业务、产品/运营	多 Agent + 工作流 双模式	强(原生)	部分支持(目前通过市场里的社区 MCP 插件,如 MCP SSE / MCP Agent Strategy 间接支持,无官方原生 MCP Server/Client)	低
Dify	技术团队、自托管需求	工作流 + Agent	中(支持但弱于扣子)	支持(v1.6.0 / 2025-07 起原生双向,v1.8.0 / 2025-08 加 OAuth 资源发现)	中
n8n	技术团队、跨系统集成	工作流 + 原生 AI Agent 节点	中(节点式)	部分(2025-04 v1.88.0 起正式节点化,Server Trigger + Client Tool)	中高
Power Automate	微软生态、外企	工作流 + AI Builder	中(通过 Copilot Studio)	弱	中
Copilot Studio	M365 深度用户	Agent + 主题流	强(M365 联动)	支持(2025 年 Build 大会公布、随后 GA,可连接远程 MCP Server 作为工具;2025-10 起再增 MCP Resources 预览)	中

一句话选型:

• 业务/运营/老板 → Coze / 扣子
• 后端 / 想私有部署 → Dify
• 系统集成 / 复杂链路 → n8n
• 全公司用 M365 → Copilot Studio + Power Automate
• 想"全都要" → n8n 调 Coze / Dify API 当底座,n8n 负责跨系统编排

⚠️ 平台风险提示:扣子/Coze 的插件市场变化较快,具体插件名以你登录后看到的为准;Dify 和 Copilot Studio 的 MCP 支持在快速演进,本文写于 2025 年中,后续可能已更新。

---

四、原理小结

AI Agent 编排流水线,核心就是 3 件事:

1. 分工(Decomposition):把"做周报"这种模糊大任务,拆成"拉邮件 / 查数据 / 写报告"3 个明确小任务,每个 Agent 各管一摊。别让一个 Agent 干所有事,会又慢又乱。

2. 调度(Orchestration):主控 Agent 或工作流,决定"谁先谁后、谁的结果传给谁、谁失败了怎么办"。调度的本质是显式状态机,不能"凭感觉"。

3. 工具(Tools):Agent 不是"会思考的 Chatbot",它之所以能干活,是因为背后有真工具——邮件 API、SQL 数据库、飞书 SDK。MCP 协议的本质,就是把"工具接入"这件事标准化:以前每接一个工具要写适配代码,以后只要工具按 MCP 协议暴露接口,Agent 就能直接用。目前 MCP 还在早期,扣子/Dify 都是部分支持,但方向确定——未来 1–2 年会成为事实标准。

最后也是最重要的一点:AI Agent 不是万能。它能做"按部就班、有明确数据源的活儿",但做不了需要深度业务判断、跨团队博弈、政治敏感度的事。把它当"能干活的实习生",不是"能决策的经理"。

五、避坑指南

1. 把 Agent 当"全能助手",结果让它干超出能力的事 踩坑表现:让 Agent 自己写 SQL、自己删数据、自己发对外邮件。 正解:给 Agent 的工具上"白名单 + 最小权限",SQL 用模板,邮件插件只授读取,发对外消息必须人工二次确认。

2. 提示词写得"模糊又开放",Agent 自由发挥跑偏 踩坑表现:"帮我整理本周邮件"——结果把广告邮件、垃圾邮件都整理进来了。 正解:提示词要有"边界 + 过滤规则 + 输出格式"三件套。参考本文给的 3 套模板,套"边界(Boundary)"段。

3. 不做"分层安全",Agent 跑飞了一发不可收 踩坑表现:Agent 误调用了"删除邮件"接口,老板邮件全没了。 正解:只读账号 + 关键字黑名单(INSERT/DELETE/DROP)+ 每步显式判断节点。三层缺一不可。

4. 直接接真实生产数据,一出错就崩业务 踩坑表现:Agent SQL 写得有问题,生产数据库报错,业务停了。 正解:先用 mock 数据 / 测试库跑通,通过后再切真实账号,期间所有操作日志留痕。

5. 忽视成本,Agent 调用爆量账单吓人 踩坑表现:Agent 配了"每封邮件都让 LLM 摘要",周一来 500 封邮件,token 费用爆表。 正解:给 Agent 加"输入长度截断 + 调用频次限制",小任务用便宜模型(GPT-4o-mini、豆包·通用模型 Lite (doubao-lite-32k) 等),大任务才上主力模型。

六、进阶延展

跑通本文的"3 Agent 周报流水线"之后,你可以往这几个方向延伸:

• 接 n8n 当"跨系统总控":Coze 负责 AI 思考,n8n 负责跨 SaaS 触发(Jira、Slack、Notion、企业微信、钉钉全打通),两者通过 HTTP / Webhook 互调;
• 接 Dify 做企业私有部署:扣子数据在云上,有些公司(金融、医疗、政企)需要私有化,把 Agent 迁到自托管 Dify;
• 接 Copilot Studio 打通 M365:如果你公司全员用 Teams / Outlook / SharePoint,用 Copilot Studio 搭 Agent 能直接吃 M365 数据;
• 用 MCP 协议接入"标准化工具":Anthropic 官方有 MCP Server 列表(数据库、文件系统、GitHub、Slack 等),按文档接进来,Agent 就能像"插 USB 一样"扩展能力;
• 把"工作流"升级成"Agent 团队":从 3 Agent 扩到 5 Agent、10 Agent,加一个"周报评审 Agent"互相挑刺,加一个"客户画像 Agent"做个性化建议;
• 学习 LangChain / LangGraph 自建 Agent 框架:当你发现扣子/Dify 满足不了"超复杂业务逻辑",就可以用 LangChain / LangGraph 写代码版 Agent,自由度最高但门槛也最高。

一句话:Agent 编排不是"装个扣子就完事",而是一个"工具选型 + 提示词工程 + 权限治理 + 试运行迭代"的综合工程。跑通一次之后,后面就是"复制粘贴 + 微调"的活儿了。

---

📌 下一步:想了解"怎么把 Excel/VBA 也能接进 Agent 流水线",可以看系列里 B20《自动化流水线》和 B25《批量 Excel》;想看企业级落地(权限/审计/合规),可以看 A5《安全红线》和 C5《低代码审批流》。

🎓 CTA:vba.net 的《AI 办公实战训练营》(L4 综合实战方向)已经把"Agent 编排"做成 4 周打卡作业,陪跑企业落地。有兴趣的可以戳 vba.net/c6-agent 看课程大纲。