Reddit AI Agent - 2026-06-28¶
1. 人们在讨论什么¶
1.1 枯燥但可靠的工作流持续压过智能体方案（🡕）¶
今天 Reddit 上最强的共识是：很多昂贵的“AI 智能体”方案，一旦操作者把真正的决策边界梳理清楚，最后还是会收敛成直接的工作流自动化。这与其说是反 AI 叙事，不如说是一再出现的范围界定建议：当输入和分支都稳定时，就该用自动化；只有面对杂乱的入站工作时，才该把模型判断留在流程里。
u/Decent-Phrase-4161 提到，他们曾给一家营养补剂品牌报出 5,200 美元做一个 AI 库存智能体，后来却用一个 700 美元的工作流替代：检查 Shopify 库存、与固定补货点比较，再发送预写好的供应商邮件（《I charge clients more to NOT build an AI agent.》）（154 分，55 条评论）。同一帖子里也明确给出了反例：一家物业管理公司的收件箱里混杂着管道和电路投诉，这种场景就确实值得用智能体，因为进来的文本很杂乱，必须靠解释来判断。u/Common_Dream9420（得分 5）说，“它是闹钟，不是大脑”这句话之所以有效，是因为真正的问题不在于智力，而在于人们想买一个“看起来更高级”的东西。
u/Due-Guard221 在 《I’ve made around $20k+ building automations, and the biggest thing i learned is that most people are selling ai completely wrong!》（27 分，11 条评论）中，也从客户项目角度提出了同样“先看采用成本”的观点。OP 认为，最好的方案应该留在团队已经在用的 email、WhatsApp、表格和 CRM 里；而 u/Sad-Slide9083（得分 5）则把这一点整理成了一份清单：找出最痛的交接点，量化错误输出的代价，并让第一版以“先审查再执行”为前提。
u/Warm-Reaction-456 在 《4 AI workflows that are just scripts (and the one that actually needs an agent)》（12 分，13 条评论）里，把这条边界进一步压缩成一个更简单的测试：提醒、触发式数据搬运、关键词分类、模板化报告，本质上都还是脚本；而像支持收件箱这种消息意图不断变化的场景，才是智能体开始真正体现价值的地方。u/donk8r（得分 4）又把话说得更直接：如果整个分支结构都能提前画出来，那它就是工作流，不是智能体。
讨论要点： 大家反复追问的实际问题不是“模型能不能做这件事？”，而是“这个流程里到底哪一部分才是真正可变的？”社区持续奖励那些把模型当成狭窄解释器、嵌在其余确定性系统中的帖子。
与前日对比： 这一主题相比 2026-06-27 更强了。昨天的高赞帖子还只是说钱花在数据管道和审查队列上；今天同样的直觉已经变成更强的“反过度构建”规则，伴随着明确的价格对比，以及反复出现的“输入杂乱 vs 固定规则”判断标准。
1.2 验证器、评估与预算闸门从理论问题变成了日常痛点（🡕）¶
“先有验证器”的智能体设计依然处于核心位置，但今天的讨论已经从基准测试层面，进一步走进了 CI、合规打分和 token 经济学。数据集显示，团队已经不只是问一个循环能不能跑通，而是在问：怎样才能避免它烧钱、拖慢合并，或者把本来正确的安全行为判错。
u/brennhill 在 《After going through ~15 agentic-loop papers (the wins and the failures), the thing that predicts success is the verifier, not the model》（47 分，33 条评论）中指出，编译器检查、测试以及可机械验证的奖励机制，才解释了那些真正可信的成功案例；没有硬性检查的循环，要么会漂移，要么会反过来“玩弄”测试框架。链接中的 LoopRails 一文 也以公开案例说明了同一点，比如 ComPilot、AlphaCodium 和 o3 的高算力 ARC-AGI 运行。在评论串中，u/Dependent_Policy1307（得分 3）说，一个真正有用的生产验证器，应该检查命令输出、trace ID、变更文件、成本、延迟，以及明确的停止原因。
u/Evening-Plan-7956 在 《The loop engineering trend is a financial nightmare》（42 分，39 条评论）中，把成本问题推到了前台，认为如果团队不先优化上游数据管道，递归式编码循环可能会在一个糟糕的边界情况上烧掉数百万 token。帖子还特别提到，像 Firecrawl 那样的预处理基础设施，就是人们正在模型前端插入的一类更便宜的组件。
最具体的工作流痛点来自评估相关帖子。u/NowHaraya 在 《agent eval latency added 18 minutes to our CI. how are you running this without killing dev velocity?》（9 分，13 条评论）中说，一个阻塞式的智能体评估闸门，把 p99 构建时间从 6 分钟推高到 24 分钟。u/Sad-Slide9083（得分 1）的回应是一种分层模式：每个 PR 都跑快速且确定性的检查，合并前只跑变更区域 trace，而把完整、重评委模型的套件留到夜间或金丝雀环境。
u/platinum_oracle 在 《testmu’s adversarial generation flagging our agent’s refusal behavior as compliance violations. anyone tuned this?》 中报告了另一类评估失效（19 分，12 条评论）。他们那个接近法律场景的智能体，明明正确地拒绝了税务和法律建议，但评估器仍把这种拒答惩罚成“不够有帮助”。u/leo-agi（得分 1）认为，受监管场景需要单独的“拒答正确性”评分，而不是强迫通用的 helpfulness 评分器把拒答也视作成功。
讨论要点： Reddit 反复给出的实际答案是“关注点拆分”：合并前跑确定性的冒烟测试，高风险动作加人工或策略闸门，不同场景类型使用不同评分器，而不是依赖一个通用的“helpfulness”指标。
与前日对比： 这一主题较 2026-06-27 上升。昨天的报告已经把验证器和维护拖累作为重点；今天又新增了 3 类更尖锐的一线抱怨：CI 变慢、评估集膨胀，以及合规智能体在“有意拒答”时仍被错误打分。
1.3 n8n 开发者持续发布可审计的垂直助手和控制平面（🡕）¶
开发者热情依然集中在 n8n，但最可信的项目已经不是通用 copilot，而是那些有可见系统边界、受限工具、显式状态或面向操作者控制面的系统：前台接待员、修复智能体、控制平面，以及分类流水线。
u/Charming_You_8285 分享了 《I built an AI receptionist for a pet clinic.》（63 分，17 条评论），其中包括 WhatsApp 接单、GoHighLevel 联系人检查、预约查询、预约、取消和改期。配图让这个工作流变得“可读”而非神秘：触发器、校验、CRM 查询、Gemini 模型、Redis 记忆，以及具体的预约工具。在评论里，u/Mlnchlc（得分 3）马上推动这个方案朝更确定性的意图路由和预取方向改进，以降低幻觉风险。
u/ageniusai 贴出了两个更偏控制面的构建。《I built an agent that auto-diagnoses and repairs broken n8n workflows》（37 分，10 条评论）描述了一个 LangGraph 修复循环：Claude 提出修复方案，OpenAI 负责审查，普通代码执行确定性的 diff 闸门，而写入动作只会在快照与回滚保护之后进行。公开的 self-healing-ops repo 也印证了这一架构，并且默认开启 DRY_RUN。与此同时，《I open-sourced a self-hosted "command center" for managing multiple n8n instances. Looking for testers.》（17 分，8 条评论）链接到了 AgeniusDesk CE，其 README 描述了全局错误流、OpenTelemetry 追踪、token/成本跟踪、代码实验室，以及一个仪表盘上的智能体集群管理。
u/kalousisk 则在 《Feature Requests organising pipeline》（8 分，10 条评论）中把范围收得更窄。链接的 feature-request-pipeline 仓库 展示了 Gmail/Typeform/webhook 输入流、Gemini 2.5 Flash Lite 请求识别、紧急程度分类、Google Sheets 记录，以及专门的错误工作流。尽管互动量较低，但它依然符合当天更广泛的倾向：偏好可审查、单一用途的系统。
讨论要点： 那些得到正面反馈的构建帖子，依然不相信模型自治本身。它们最有力的主张都落在可见分支、写入闸门、记忆放置、trace 和狭窄作用域上。
与前日对比： 这一主题较 2026-06-27 仍在上升，但重心有所移动。昨天 n8n 的讨论主要集中在接待员和编码节点实验；今天则扩展到了修复循环、多实例控制平面，以及可复用的分类基础设施。
2. 令人困扰的问题¶
实际是工作流的问题，却被错误界定成智能体问题¶
高严重度。u/Decent-Phrase-4161 说，他们见过最昂贵的错误，就是为一个本可由固定库存阈值和模板化供应商邮件解决的任务，花 5,000 美元去做 AI 智能体（《I charge clients more to NOT build an AI agent.》）（154 分，55 条评论）。u/Warm-Reaction-456 在 《4 AI workflows that are just scripts (and the one that actually needs an agent)》（12 分，13 条评论）中提出了同样的抱怨，而 u/Due-Guard221 则表示，企业通常真正需要的，是在 email、WhatsApp、表格和 CRM 里修好已经断裂的交接流程，而不是一个新的“智能体式工作台”（来源）。当前的应对模式，是让第一版保持“先审查再执行”并贴合原有渠道。这个方向依然值得做，因为团队还在持续花钱，反复踩进同样的范围界定错误里。
评估栈既昂贵又缓慢，而且有时还会把安全判断错¶
高严重度。u/NowHaraya 报告称，一个阻塞式评估闸门给 CI 增加了 18 分钟，并迫使工程师把改动攒成批次，而不是持续交付（《agent eval latency added 18 minutes to our CI. how are you running this without killing dev velocity?》）（9 分，13 条评论）。u/Only_Midnight_8557 补充说，大约 340 个评估场景里，有 80 个在 6 个月里从未报出失败，而大约 40 个却一直重复报同一种失败模式（《we have ~340 eval scenarios. ~80 of them never flag anything. how are you pruning your eval set?》）（10 分，8 条评论）。合规案例更尖锐：u/platinum_oracle 表示，Testmu 和 Patronus 都会因为一个接近法律场景的智能体正确拒绝受监管建议，而对它进行惩罚（《testmu’s adversarial generation flagging our agent’s refusal behavior as compliance violations. anyone tuned this?》）（19 分，12 条评论）。当前的权宜方案包括拆分套件、缓存场景、自定义评分器和黄金拒答集，这说明这个类别仍然建设不足。
可靠性工作总是藏在重复发送、webhook 噪声和审查负担里¶
中高严重度。u/kumard3 说，在 n8n 里最帮他们节省调试时间的节点，不是什么 AI 节点，而是一个普通的 Function 节点，用来在发邮件、写数据库和调用付费 API 之前做幂等性保护（《the n8n node that has saved me the most debugging time isn't the AI node — it's a plain Function node that checks state before doing anything》）（11 分，8 条评论）。u/Charming_You_8285 说，他们宠物诊所机器人最初会因为 Meta webhook 状态事件而给自己的消息回复，评论区也推动他们把预约逻辑做得更确定（《I built an AI receptionist for a pet clinic.》）（63 分，17 条评论）。u/TruthIsAllYouNeed_ 则总结出更普遍的版本：AI 让代码生成更便宜了，但也让上下文、边界情况、清理和验证变得更重要（《AI didn’t remove engineering work. It moved the hard part somewhere else.》）（16 分，15 条评论）。这个方向值得构建，因为今天的答案依旧只是零散的防护、手工状态检查和人工审查。
3. 人们期望的功能¶
面向受监管智能体、具备策略感知能力的评估器¶
这是数据集中最明确的显性需求。u/platinum_oracle 想要一种清晰的方法，告诉对抗性评估器：在法律或税务场景里，正确行为应该是拒答，而不是生成答案（《testmu’s adversarial generation flagging our agent’s refusal behavior as compliance violations. anyone tuned this?》）（19 分，12 条评论）。u/leo-agi（得分 1）希望增加一个单独的策略正确性维度，而 u/Wright_Starforge（得分 1）则认为，对抗式生成器可以改变施压方式，但不该掌握最终判定标签。这是一个现实需求，而不是愿景式需求，因为用户已经非常清楚自己缺的是什么工件。机会：直接。
适配团队现有渠道、以审查优先为前提的自动化¶
多篇高信号帖子都在呼吁一种系统：它能在现有收件箱、CRM、表格和消息渠道里工作，而不是要求团队切换到一个新的 AI 工作区。u/Due-Guard221 说，行为改变是许多本来合理的自动化项目失败的原因；而 u/Sad-Slide9083（得分 5）则给出了一份以痛点、错误代价和审查边界为核心的“工作流优先”资格判断清单（《I’ve made around $20k+ building automations, and the biggest thing i learned is that most people are selling ai completely wrong!》）（27 分，11 条评论）。u/Decent-Phrase-4161 也从购买方角度表达了同样诉求：如果输入是固定的，那一个能消除每天 40 分钟运营痛苦的工作流，会胜过一个更“高级”的智能体（来源）。机会：直接。
用于安全自动化集群和修复循环的控制平面¶
开发者帖子隐含出一种更统一的操作者基础设施需求：错误流、追踪、密钥、审批点、回滚和安全写回。u/ageniusai 给出的一个答案是 AgeniusDesk CE，这是一个多实例 n8n 指挥中心，链接自 他们的 Reddit 帖子（17 分，8 条评论）；同一作者的 self-healing-ops repo 则在智能体写出的补丁外层，加上了跨厂商审查、确定性 diff 闸门和回滚（《I built an agent that auto-diagnoses and repairs broken n8n workflows》）（37 分，10 条评论）。公开的 Dropbox 的 Nova 一文 也在企业规模上指向同一个方向：把编程智能体做成共享平台，配套隔离会话和验证命令。机会：竞争激烈。
更便宜的循环治理与评估路由¶
关于循环成本的帖子不只是抱怨账单，更是在追问更好的预算纪律。u/Evening-Plan-7956 表示，如果没有上游预处理和更好的停止条件，循环工程最终会变成“巨额 API 账单”（《The loop engineering trend is a financial nightmare》）（42 分，39 条评论）。u/NowHaraya 和 u/Only_Midnight_8557 想要的是更轻量的冒烟测试套件、面向变更区域的 trace，以及修剪陈旧评估场景的方法，而不是在每次提交或每个历史遗留场景上都付出完整成本（来源；来源）。机会：直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| 确定性脚本 / cron / if 语句 | 方法 | (+) | 当分支已知时，成本低、可解释且可靠 | 一旦输入变得杂乱或含糊，就会失效 |
| n8n | 工作流自动化 | (+) | 让触发器、分支、重试和交接都可见；适合客户交付和狭窄助手 | 仍然需要明确设计幂等性、错误处理和审批 |
| LangGraph | 智能体编排 | (+/-) | 适合路由式修复、审查循环和受限的智能体阶段 | 如果循环不设终点，容易带来评估、延迟和 token 额外开销 |
| Google Sheets | 轻量数据存储 | (+/-) | 很适合内容日历、日志和简单的操作者工作流 | 经常被批评不适合作为长期数据库或高可靠后端 |
| Airtable | CRM / 结构化存储 | (+/-) | 适合管理线索状态、房产元数据，以及像 Welcome Sent 这样工作流可见的字段 |
需要仔细过滤 webhook 并设计后续逻辑，避免循环和陈旧状态 |
| Gemini / Gemini 2.5 Flash Lite | LLM | (+) | 足够便宜，适合接待员和功能分类工作流 | 用户仍报告说，如果路由不够收紧，会出现幻觉和上下文窗口压力 |
| OpenAI models | LLM | (+/-) | 用于提示词扩展、面向客户的逻辑，以及独立审查角色 | 成本、依赖风险和错误激励仍要求在输出外层加确定性闸门 |
| OpenRouter | 推理网关 | (+/-) | 模型接入面广，也能绕开缓慢的提供商 | 它仍是按 token 计费的一层，在大规模场景下未必胜过专用端点或自托管 |
| Together.ai | 推理提供商 | (-) | 丰富的模型目录让用户最初愿意继续使用 | 讨论串主要集中在价格压力和不稳定的延迟 |
| KIE.AI + nano-banana-2 | 图像生成 | (+/-) | 与提示词扩展搭配时，能把普通产品照片做成风格化商品图，单张成本约 0.11 美元 | 上传文件和结果 URL 会过期，因此还得单独补上持久化存储 |
整体满意度最高的情况，是工具把控制面讲清楚，而不是承诺自治。今天的实用栈看起来更像“可见工作流 + 狭窄模型调用”，外面再加上重试、幂等和审批防护。主要迁移路径，是从“直接让智能体处理”转向“先上工作流，只在输入杂乱的地方加模型，再在写路径外面套确定性检查”。在供应商层面，大家评判竞争主要看延迟、路由广度和稳态经济性，而不只是品牌。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| 宠物诊所 AI 接待员 | u/Charming_You_8285 | 处理诊所的 WhatsApp 接单、预约、取消、改期和预约查询 | 为小企业提供一个边界清晰的助手，处理重复性的前台排期工作 | n8n、WhatsApp Business、GoHighLevel、Gemini、Redis | 早期原型 | 帖子, gist |
| Self-Healing Ops | u/ageniusai | 诊断失败的 n8n 工作流、起草修复、获取独立审查，并执行受限修复 | 减少夜间工作流故障，同时避免让单一模型悄悄改写生产流程 | LangGraph、Claude、OpenAI、n8n API、Slack | 早期原型 | 帖子, repo |
| AgeniusDesk CE | u/ageniusai | 集中管理多个 n8n 实例的错误流、trace、代码编辑和智能体管理 | 给操作者一个统一位置，查看整个工作流集群里哪里出问题了 | Python、Docker、OpenTelemetry、n8n、LangGraph/PydanticAI support | 测试版 | 帖子, repo, demo |
| AI 功能请求优先级整理器 | u/kalousisk | 从 Gmail、Typeform 和 webhook 采集反馈，对功能请求分类，并记录优先级输出 | 把分散的产品反馈变成一个带日志和通知的狭窄分诊工作流 | n8n、Google Gemini 2.5 Flash Lite、Google Sheets、Gmail、Typeform | 测试版 | 帖子, repo |
| AI 产品照片工作室 | u/ageniusai | 通过单个表单，把普通产品照片转成风格化棚拍图 | 为小型商品目录降低产品摄影的成本和协作开销 | n8n、OpenAI、KIE.AI nano-banana-2 | 测试版 | 帖子, repo |
| 每日产商品简报工作流 | u/OrneryNegotiation320 | 从表格中读取已排期商品，生成 HTML 邮件，并只在确有内容时发送 | 用确定性的定时流程替代重复的商品/简报准备工作 | n8n、Google Sheets、Gmail、HTML email | 已发布 | 帖子, template |
- 阶段 —— 项目所处的位置：已发布（线上/生产）、测试版（可用但未完成）、早期原型（早期原型），或 RFC（想法/提案，尚无可运行代码）
- 技术栈 —— 项目所基于的语言、框架、模型或服务
- 解决的问题 —— 推动这个构建出现的具体痛点或缺口
- 链接 —— GitHub repo、项目站点、demo、博客文章，或项目所在的位置
宠物诊所接待员是当天最清晰的“边界可见的垂直助手”案例之一。帖子用文字描述了预约流程，而图片之所以重要，是因为它把精确的工具图谱暴露出来，而不是藏在一个笼统的“AI 接待员”说法后面。
这种可见性正是评论区所奖励的东西。u/Mlnchlc（得分 3）立刻建议把更多意图分类和预约预取前移到确定性逻辑里，这也正是整个数据集一直在尝试做的事：缩小模型的动作表面。
Self-Healing Ops 和 AgeniusDesk CE 则把同样的直觉放到了运营层，而不是前台层。公开的 self-healing-ops 仓库 记录了一条审批路径：Claude 负责提出方案，OpenAI 负责审查，普通代码执行 diff 闸门，而修复动作则在快照与回滚之后进行。公开的 AgeniusDesk CE 仓库 描述了一个多实例控制平面，具备追踪、token 成本可见性、密钥管理和智能体集群支持；这更强烈地表明，开发者既想要模型调用，也同样想要运营层的操作面。
AI Product Photo Studio 的互动量较小，但具体程度异常高。帖子和公开的 仓库 README 写明了精确流程：上传产品图、用 OpenAI 扩展场景提示词、在 KIE.AI 上运行图生图，并轮询直到结果准备完成；作者估算单张约 0.11 美元，同时提醒如果不补上存储，输出 URL 会过期。
这张图重要，不只是因为它证明了价格，更因为它证明了这个工作流的输出形态。它也说明了为什么 README 里的提示词约束很关键：变化的是场景，产品标签本身则保持完整。
这个简报模板是另一个很有信息量的工件，因为它展示出许多重复性工作其实几乎不需要什么“智能体”逻辑。工作流图清楚展示了一条简单的定时路径：读取表格行、筛选出当天商品、拼装 HTML、读取收件人，并且只有在确实有内容要发时才发送。
反复出现的构建模式是：最可信的开发者始终在模型外面打包清晰的硬边界。他们暴露的是触发器、字段、审批点、回滚、过期限制或精确的状态迁移，而不是声称一个通用智能体会自己把剩下的都搞定。
6. 新动态与亮点¶
Dropbox 的 Nova 文章表明，编程智能体正在变成内部平台¶
u/nilukush 带出了 Dropbox 公开的 Nova 一文，并在 《From Dropbox: Nova, their internal platform for coding agents》（6 分，2 条评论）中讨论了它。这篇文章之所以重要，是因为它把编程智能体框定为共享基础设施：有隔离会话、验证命令、修复不稳定测试的循环，以及迁移工作流，而不是一个更好用的聊天框。
公开的开源智能体项目正收敛到“不同模型提方案，确定性系统做决定”¶
这种模式在 self-healing-ops 中表现得尤其清楚：提出方案的模型不能批准自己的补丁，审查模型没有写入路径，而最终的 diff 闸门和回滚路径依然由确定性代码掌控。相比通用智能体 demo，这是一种更成熟的运营信号，因为安全边界是公开写清楚的。
低成本媒体与传播工作流正以可复用工件的形式被分享，而不只是客户项目¶
AI Product Photo Studio 仓库 和已发布的 每日产品简报模板 之所以突出，是因为两者都交付了完整的工作流工件，并明确写出了运行约束：前者给出大致单图成本和会过期的 URL，后者则明确是一条非 AI 的定时流程。这比单纯的“我们给客户做了这个”轶事，更能说明复用信号已经出现。
7. 机会在哪里¶
[+++] 具备策略感知能力的验证器与评估基础设施 —— 证据来自那篇“验证器优先”的论文综述、Testmu 对拒答打分失误的案例、18 分钟 CI 闸门线程，以及陈旧评估修剪线程。人们想要的是确定性的冒烟测试、拒答正确性打分、面向变更区域的评估路由，以及只在风险足以证明其合理性时才花模型预算的更好方法。
[+++] 贴合现有渠道的工作流式自动化 —— 高互动量的咨询类帖子一直在重复同一件事：真正的收益通常在 email、WhatsApp、表格、CRM 和已经存在的固定工作流里，而不是在一个新的智能体壳层里。最强的机会依然是“结果优先”的改造方案：在不逼团队重学工作方式的前提下，减少重复劳动。
[++] 面向工作流集群和安全修复的控制平面 —— AgeniusDesk CE、Self-Healing Ops 以及 Dropbox 的 Nova 文章，都指向模型之上的一个增长中层次：trace、审批边界、写入闸门、回滚、密钥和多实例可见性。这个信号很强，但市场很可能会被相互重叠的“智能体运维”叙事迅速挤满。
[+] 受成本治理约束的创意与内容自动化 —— 产品照片工作流和简报模板都表明，市场对可复用、低摩擦的工作流有需求：它们能把重复内容工作转成边界清晰的系统，并且明确成本与存储约束。这还是一个新兴机会，而非主导性机会，但相关工件已经很具体。
8. 要点总结¶
- 今天 Reddit 上最清晰的 AI 智能体规则是：如果分支结构已知，就别再叫它智能体。 互动量最高的帖子一直在画同一条线：一边是固定工作流，另一边是真正杂乱的输入。（来源）
- 验证器质量很重要，但运行验证器循环的价格同样重要。 数据集把偏基准测试风格的验证器讨论，直接和 CI 变慢、陈旧评估套件以及循环成本抱怨联系到了一起。（来源）
- 受合规约束的智能体仍然缺少合适的评分层。 最明确的未满足需求不是更好的模型，而是一个能识别“在受监管领域里，拒答才是正确输出”的评估器。（来源）
- n8n 开发者持续发布的是带有可见状态、工具和回滚面的系统，而不是模糊的自治。 接待员、修复智能体、控制平面和功能分诊工作流，都把具体的动作边界暴露了出来。（来源）
- 最可复用的新工件，是那些约束明确的小型工作流。 产品照片工作流给出了输出定价并记录了 URL 会过期，简报模板则展示了一条完全确定性的定时发送路径。（来源）