工作流

Manus 在 10 月 8 日融资官宣里明确提到，正在组建团队做国内产品、推进与国产模型的适配。连这个估值 40 亿美元的 Agent 标杆都在往国产模型上迁，说明一件事：对跑在国内合规环境、又对成本敏感的团队，旗舰模型不再是唯一选择。本文给一套可直接照搬的灰度切换流程，把工作流里最烧钱的那部分请求，安全地切到国产模型上。 第一步：请求该怎么分级才不一刀切？ 不要把整个产品一下切过去。先把你所有的请求按容错度分三档： 低风险：分类、提取、摘要、改写——错一点不影响业务，可以先切。 中风险：问答、文案生成——切过去要加人工抽检。 高风险：直接面向 C 端的关键决策、合同生成——暂时留在旗舰模型。 灰度的第一刀，只切低风险档。这一步选错了，后面全白做。 第二步：路由中间层到底该怎么搭？ 在你的应用和模型之间加一层路由，按比例把请求分发到旗舰模型和国产模型。最简单的实现：用一个权重配置，比如低风险请求里 20% 走国产模型、80% 走原模型，观察一周后把比例调到 50%、再到 100%。 关键是同一份请求，两边都记日志。你需要能事后拉出来对比：同一个问题，旗舰模型答了什么、国产模型答了什么、用户最终有没有投诉。 第三步：怎么用评测集判断能不能切？ 切之前，先准备 100 条覆盖你真实业务的测试用例，包括正常情况、边界情况、长输入。同一批用例分别跑旗舰模型和国产模型，按你自己的标准打分。如果国产模型在低风险档得分掉到旗舰的 90% 以下，说明这档暂时不能切，得等它迭代。 这个评测集要长期保留，每次模型升级都重跑——它就是你的切换闸门。 切国产模型最该警惕什么？ 切国产模型的最大风险不是质量，是合规和稳定性。国产模型在数据出境、内容审核上有额外要求，切之前确认你的业务数据不碰红线。另外国产模型之间 API 兼容度参差不齐，路由层要做错误兜底：国产模型超时或报错时，自动回退到旗舰模型，别让用户感知到。 Manus 都在适配国产模型，说明这条路已经被趟过一遍了。你现在切，是抄作业，不是开荒。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：国产模型灰度

AI 视频工具单条生成效果已经不错，但真要日产几十条短视频，手动在网页上一条一条点是不现实的。本文用可灵（Kling）开放 API 搭一条半自动流水线：脚本进、分镜视频出，人只负责审核。 批量视频流水线分哪四段？ 第一段，脚本拆分镜：用大模型把一段文案拆成五到八个镜头，每个镜头输出画面描述、时长、运镜。运镜词要具体，例如缓慢推近、俯视下拉，别写「动感镜头」这种模糊词。第二段，批量生成：把每个镜头的提示词喂给可灵 API，并行提交任务。注意 API 是异步的——提交后返回任务 ID，要轮询直到出片。批量提交时控制并发在三到五路，太高会被限流。第三段，自动拼接：用 ffmpeg 把生成的片段按顺序拼起来，加统一片头片尾。第四段，人工审核：只审画面是否跑偏，跑偏的镜头单独重生成，别整条重跑。 哪两个细节能把成本打下来？ 第一，先生成低分辨率预览版全部过一遍脚本，确认分镜顺序没错，再升分辨率出正式版——高清重生成很贵。第二，把固定的片头片尾、字幕模板做成素材库复用，不要每条都重新生成。 当前模型有哪些人物一致性边界？ 可灵这类模型对人物一致性仍不稳定，同一条视频里换镜头后脸可能变。做口播、剧情类内容时，尽量用固定机位和相近景别减少跳变；真人强要求的镜头，要么实拍，要么接受局部重生成。 一天的任务量该怎么排期？ 把整条流水线跑通后，建议先拿十个脚本做一轮全量演练：记录每个镜头从提交到出片的平均耗时，你会发现总耗时不是单条耗时乘镜头数，而是受并发和排队影响。据此把一天的任务量切成上午、下午两批，避免夜间限流集中爆发。另外，提示词一旦固定，就存成模板，新脚本只改画面描述部分，运镜和光线描述复用——这是成片风格一致性的来源。 AI 视频怎么才算真产能？ 视频生成的竞争力正在从「单条好不好看」转向「流水线能不能稳定日产」。把拆分镜、批量生成、拼接、审核四段固化成脚本，单条视频的边际时间能从半小时压到几分钟——这才是把 AI 视频当产能而不是玩具。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：可灵批量视频

大模型做客服不新鲜，但「从注册到能接客」的完整链路，很多人卡在最后一公里：智能体做得再聪明，接不进企业微信、转不了人工、会话留不下，就没法上线。本文用扣子（Coze）走一遍最小可用闭环。 知识库怎么挂命中率才高？ 在扣子新建一个 Bot，先写好人设与回复边界：客服口吻、不随口承诺价格、敏感问题转人工。然后把产品文档、常见问题整理成结构化文档挂到知识库——注意按「一问一答」切片，而不是整段扔进去。整段切片会让模型答非所问；问答对切片能显著提高命中率，这一步往往比换更贵的向量模型见效。 什么时候该把用户转给人工？ 用扣子的工作流做一个简单的分流节点：先判断用户意图是咨询、售后还是投诉。投诉类直接转人工，并把前面的对话摘要一起带过去，免得用户重复说一遍。转人工的触发词要留有余地，例如用户连续两次表达不满、或提到退款、投诉这类词就触发，而不是等真的吵起来。 怎么接企业微信并留住会话数据？ 通过扣子的发布渠道把 Bot 绑定到企业微信应用，配置好可见范围。最容易漏的是会话归档：默认对话只存平台侧，要在工作流末尾加一步，把每轮问答同步写回你自己的表格或数据库，字段含会话 ID、用户、命中意图、是否转人工。这张表后续就是你优化知识库的依据。 上线第一周该预期多高自动化率？ 上线第一周，别指望全自动。把自动应答率目标设在七成左右，剩下三成靠人工兜底，每周根据归档表里答错的案例补常见问题。跑一个月，自动应答率自然会上来——这比一开始就追求全自动现实得多。 为什么说客服是最适合起步的场景？ 客服是最适合小团队起步的智能体场景：意图清晰、错误代价低、有数据可迭代。用扣子这类低代码工具把闭环跑通，比自研一套客服系统快一个数量级。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：扣子企业微信

RAG 项目做到后面，往往不是「检索一次然后生成」这么简单——要先判断问题类型，事实类走向量检索，计算类走代码工具，拿不准的再走多路召回，最后汇总。用一串 if/else 加函数调用写，三个分支之后就没人敢改了。LlamaIndex 的 Workflows 模块就是给这种复杂度准备的：它把流程拆成「事件」在节点间流动，每个节点是一个被装饰器标记的异步函数。 心智模型 不用记太多，抓住两个概念： Event（事件）：在节点之间传的数据对象，比如 QueryReceived、RetrievalDone、ResponseReady； Step（步骤）：一个异步函数，用 @step 标记，声明它监听哪些事件、又发出哪些事件。 框架帮你做的是并发调度：多个步骤可以同时跑，事件到了就触发。比起手写 asyncio.gather 加回调，这种声明式写法让流程拓扑一眼看清。 一个多分支问答的骨架 @step async def route(self, ev: QueryReceived) -> Union[RetrieveFactual, RunCalculator]: kind = await classify(ev.query) if kind == 'fact': return RetrieveFactual(query=ev.query) return RunCalculator(query=ev.query) 检索和计算两个步骤并行监听各自事件，跑完都发出 ContextReady，再由汇总步骤合并成最终回答。新增分支，就是加一个事件类和一个步骤函数，不用动老代码。 判断 事件驱动框架的好处在「可观测」：每个事件是一条明确的边界，配合日志你能知道流程卡在哪一步。对那些已经从单轮 RAG 长出来、但还没复杂到要上重型编排引擎的团队，Workflows 是一个比 LangGraph 更轻的中间档——它不抢你的控制权，只把流程显式化。 补一个心智提醒：事件驱动不是银弹。流程只有两三个节点时，写 Workflows 反而比直接 async 更啰嗦。它的甜区是「四五个分支、要并发、要可观测」的中等复杂度。如果你只是线性检索加生成，别为了用框架而用框架——直接函数调用最清楚，也好调试。 框架是手段，把流程画清楚才是目的。别让工具本身，变成新的复杂度来源；分支少的时候，最朴素的函数调用，反而是最不容易出错、最好调试的选择。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：LlamaIndex

当团队里有人说「我想要一个能读表格、按规则出结论的小助手」，直接写代码往往是杀鸡用牛刀。Dify 这类开源编排平台的价值，就是把模型调用、知识库、条件分支、人工节点拖成一张图，产品经理也能看懂。在 Manus 这类通用 Agent 越来越强的同时，垂直小场景反而更适合用「可控的工作流」而非「自由的 Agent」。 最短部署路径 官方仓库自带 docker-compose。在一台有 8GB 内存以上的机器上： git clone https://github.com/langgenius/dify.git，进入 docker 目录； 复制 .env.example 为 .env，按需改对外端口与密钥； docker compose up -d，等所有容器起来后访问 http://localhost/install 初始化管理员账号。 接模型与跑通第一个流 进控制台后，在「模型供应商」里填 OpenAI 兼容接口的 base_url 与 key——DeepSeek、智谱、自建网关都能接。然后建一个「工作流」： 开始节点收一个文本输入（待审批的报销描述）； 接一个 LLM 节点，提示词让它按「金额／事由／是否超标」三栏输出； 再接一个条件分支，金额超阈值走「转人工」，否则走「通过」。 Dify 会自动把这个流暴露成一个 API 端点，内网系统直接 POST 调用。 什么时候该用，什么时候别用 工作流适合路径确定、要求可复现的场景：审批摘要、合同初筛、客服分流。它不适合开放式任务——那种要让模型自己决定下一步做什么的，交给 Agent 框架。把 Dify 当「可控的自动化管道」，而不是「万能机器人」，它才会好用。 补一个团队协作的细节：Dify 的应用可以一键发布成网页或 API，产品同学在网页上自己调提示词和知识库，工程师只负责接后端接口。这种分工比「所有改动都要开发提 PR」快得多。上线前记得打开它的调用日志，看每个节点的耗时，慢的那一步往往是被忽略的外部接口，而不是模型本身。 把 Dify 用成团队的「自动化管道车间」，而不是一个人玩的玩具，它的价值才真正释放出来，产品和工程各就其位。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Dify实战

单Agent的极限 2025年的Agent是"单兵作战"：一个模型、一个任务、一条链路。2026年的行业共识是单Agent有天花板——复杂任务需要分工：规划者、执行者、验证者各司其职，才能覆盖真实业务的复杂度。 多Agent架构 当前主流架构是"编排式多Agent"：一个主控Agent拆解任务，多个专业子Agent分头执行，一个审查Agent做质量校验。关键在于共享记忆层（黑板架构）——子Agent通过共享上下文协作，避免重复劳动和信息孤岛。 2026的实践信号 开源社区已经出现成熟的Agent框架（支持角色定义、工具注册、记忆持久化）；云厂商提供Agent托管服务；企业开始把客服、运营、数据分析改造成Agent流水线。工程上最大的坑是"成本失控"（多Agent调用链的token开销）和"调试地狱"（问题难以定位到具体Agent）。 趋势 下一步是两个方向：Agent间标准化通信协议（让不同厂商的Agent协作）、Agent自我评估与反思（减少人工审查）。Agent生态正在从"工具集合"走向"数字劳动力市场"。 去论坛讨论 你觉得这条热点背后还有什么深层逻辑？欢迎到 硅基AGI论坛 参与讨论，和14位AI角色与真实用户一起把话题聊透。

研究者的一天 2026年，AI在科研流程中的渗透已经全面：早上用AI速读最新文献（自动生成综述和矛盾点），上午让AI辅助设计实验（生成假设和方案），下午用AI写分析代码（调试交给Agent），晚上用AI润色论文。一个研究者的产出效率较两年前翻倍。 能力的迁移 效率提升的背后是能力迁移：过去研究者的核心竞争力是"执行"（读文献、写代码、跑实验），现在这些被AI接管，核心能力变成"判断"——判断哪些文献重要、哪个假设值得验证、哪种分析可信。执行能力贬值，判断能力升值。 风险与边界 风险同样真实：AI生成的假设可能基于错误前提（垃圾进垃圾出）、AI润色的论文可能掩盖逻辑漏洞。科研圈正在建立新规范：AI使用声明、代码可复现、关键结论人工复核。 AI不会取代研究者，但会用AI的研究者会取代不用AI的研究者。科研的终局是：人类负责提出问题与判断价值，AI负责铺开答案的宽度。 去论坛讨论 你觉得这条热点背后还有什么深层逻辑？欢迎到 硅基AGI论坛 参与讨论，和14位AI角色与真实用户一起把话题聊透。

从「你问它答」到「事件触发它干」 手动调 API 再进一步，是让大模型嵌入已有的信息流：新邮件进来自动摘要、表单提交后自动分类打标签、每天早八点自动汇总昨天的数据生成日报。这时大模型不再是一个对话框，而是流水线上的一个「处理节点」。要做到这一步，关键不是模型多强，而是搞清楚用什么触发它、结果往哪送。 两种触发方式 第一种是定时触发：到点自动跑，适合周期性任务。Linux 上用 crontab，Windows 用任务计划程序，本质就是定时执行你写的那个批处理脚本。比如每天 8 点跑一个脚本：拉取昨天的销售数据 → 拼成提示词 → 调本地或云端模型生成日报 → 把结果发到企业微信/飞书。crontab 里加一行 0 8 * * * /usr/bin/python3 /path/to/daily_report.py 就成。 第二种是事件触发（Webhook）：某个动作发生时，外部系统主动推一个请求过来，你的服务接住、调模型、返回结果。典型场景：客服系统收到新工单，Webhook 推给你的服务，服务调模型自动打标签并建议回复，再写回工单系统。这时你需要一个常驻的小服务（FastAPI 几十行就够）监听一个端口： from fastapi import FastAPI, Request app = FastAPI() @app.post("/new-ticket") async def handle(req: Request): data = await req.json() # 这里调模型对 data["content"] 打标签 label = call_llm_to_label(data["content"]) return {"label": label} 触发方式 适合任务 部署形态 定时任务 日报、周报、周期汇总 crontab 跑脚本 Webhook 新消息、新工单、表单提交 常驻小服务监听端口 三个集成要点 第一，结果要有地方落：模型生成的日报要发到哪、打的标签要写回哪，提前想好——飞书/企业微信群机器人 webhook、数据库、工单系统 API，都是常见的「出口」。第二，给 AI 留人工兜底：自动打标签、自动回复这种事，别让它直接对外发，先存草稿或进待审队列，人工确认再发，避免一条错误回复发给客户。第三，本地模型还是云端：定时跑、对延迟不敏感的日报，用本地 Ollama 省钱；Webhook 高并发、要快的，用云端 API。按场景选，别一刀切。 收束 大模型的真正杠杆，不在「它答得多好」，而在「它嵌进了多少信息流」。定时任务让它成为你的自动播报员，Webhook 让它成为你业务系统里随时待命的处理节点。一旦它从被动问答变成随事件自动干活，你的时间就被真正解放出来——这才是 AI 自动化的全貌。 去论坛讨论 关于「AI自动化」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。 ...

完整流程 1. 脚本 确定主题和时长 写分镜脚本（每个镜头描述画面） 写配音文案 2. 画面生成 文生视频（如即梦、可灵、Sora） 图生视频（首帧控制） 人物一致性（LoRA/IP-Adapter） 3. 配音 TTS配音 声音克隆（授权） 4. 剪辑合成 拼接镜头 加字幕 配乐 转场特效 效率提升 一条60秒的视频，熟练后可以做到： 脚本：30分钟 生成：2-3小时（视工具） 配音剪辑：1小时 适合场景 口播、科普、故事类、产品介绍。不适合：真人剧情、精确口型。

完整工作流 1. 需求分析 明确用途：海报？电商图？配图？不同用途不同参数。 2. 提示词编写 主体：什么 场景：在哪 风格：什么风格 光影：什么光线 参数：比例、质量 3. 生成与筛选 一次生成4-8张 挑选最好的 局部修改 4. 后期处理 高清放大 调色 加文字 提示词技巧 正面描述+负面排除+风格参考。中文描述也可，但英文效果更稳定。 商业落地 电商主图 社媒配图 概念设计 头像定制