Reddit AI Agent - 2026-06-29¶
1. 人们在讨论什么¶
1.1 契合工作流的自动化持续压过泛化智能体宣传 (🡕)¶
今天最强的实用共识是：企业通常愿意为痛苦的交接、混乱的记录和响应时效修复买单，而不是单纯为一个新的“智能体化”界面买单。证据来自多条咨询和代理机构线程，而且它们都得出了同一条结论：把工作流留在用户已经在使用的渠道里，只在输入确实很混乱的地方加入模型判断。
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!》 （54 分，17 条评论） 中指出，团队通常并不需要新的聊天机器人或仪表盘；他们需要的是 PDF 转 proposal 草稿、CRM 清洗，以及把上下文缝进他们已经信任的 email、WhatsApp、表格和通话工作流里。评论区里，u/Sad-Slide9083（得分 4）把这总结成一份操作清单：找出痛苦的交接点、衡量错误输出的成本、让第一版以人工审查优先，并明确上线后谁来对故障负责。
u/Warm-Reaction-456 在 《I've made $100k+ building AI automations and I'll tell you what's worth building and what's a waste of money》 （30 分，38 条评论） 中把同样的边界说得更明确。OP 说，一个客户问答智能体看起来运作正常，直到它错误地告诉买家订单延迟了——而事实并非如此，这就足以让创始人在 6 周后砍掉它；同一帖子里，大家也认为线索跟进和内部报告值得做，因为它们更便宜、更快，也更容易设边界。u/Common_Dream9420（得分 1）把教训又推进了一步：真正的筛选标准是错误成本，而不是这个产品能不能被包装成 AI。
u/pranav_mahaveer 则在 《been running an AI Automation Agency for 3+ years now. here's the thing nobody tells you when you start.》 （40 分，16 条评论） 中补上了运营方视角：所谓“简单”的客户工作流，往往藏着只靠口耳相传的知识、格式不对的 PDF，以及会把干净 demo 直接击穿的脏数据。u/Sad-Slide9083（得分 1）回复说，第一份交付物很多时候应该是流程地图加上一套来自真实边界情况的回放测试集，而不是自动化本身。
讨论要点： 反复出现的论点并不是反智能体，而是模型只有在有人先定义好稳定流程边界、审查节点和错误预算之后，才能真正体现价值。
与前日对比： 这一主题相比 2026-06-28 更强了。昨天已经偏向“无聊但好用”的工作流，而不是花哨的智能体；今天同样的规则出现在更多面向业务的线程里，对行为变化、定制化部署和错误输出成本的警告也更明确。
1.2 Loop 炒作迎来更强烈的成本、漂移与确定性反弹 (🡕)¶
第二组高信号线程开始反击开放式自主循环。Reddit 用户并不是在说编程智能体没用；他们是在说，长会话、递归重试和“loop engineering”这套说法，必须被硬边界、新鲜上下文和确定性检查包起来。
u/Evening-Plan-7956 在 《The loop engineering trend is a financial nightmare》 （132 分，98 条评论） 里把这股反弹摆到台面上：一旦递归式编程循环开始把完整终端日志和聊天历史反复塞回模型，就可能迅速烧掉巨额 token 预算。附图之所以关键，是因为它捕捉到了引发整条线程反应的那句原话——“你应该设计能去提示你的智能体的循环”。
u/Future_AGI 在 《Your agent gets dumber the longer a session runs》 （5 分，18 条评论） 中描述了会话后期的失败模式：同一个模型在前几步表现良好，但随着上下文窗口被原始历史和过大的工具输出塞满，就开始重复工具调用、漏掉指令，并把自己的推理错误越滚越大。u/alexbuildswithai（得分 2）回应说，修复办法是把真实状态放在聊天外部，只把智能体下一步真正需要的那一小片上下文传给它。
u/Sufficient_Ninja_821 在 《Best attempts at making an agent deterministic as possible.》 （5 分，28 条评论） 中追问，人们究竟能把智能体行为逼近到多确定。最具体的回复并没有承诺“确定性的模型”，而是推荐“确定性的边界”：固定工具 schema、显式状态机、golden trace、重试预算和恢复测试。与此同时，u/Bladerunner_7_ 在 《Are we focusing too much on models and not enough on agent infrastructure?》 （16 分，18 条评论） 中追问，真正的瓶颈是否已经从模型转移到了基础设施上，而线程整体基本同意：记忆、重试、可观测性和提供商波动，才是生产环境失败真正发生的地方。
讨论要点： 最常见的答案，是把可靠性工作从模型里拿出来：总结已定结论的轮次、裁剪工具输出、把状态外置，并让运行框架接管重试、预算和审批。
与前日对比： 这一主题相较 2026-06-28 进一步增强。昨天的报告已经聚焦在 verifier 和 eval；今天的讨论则扩展到了 token 消耗经济学、上下文窗口漂移，以及越来越多人相信“好的运行框架”比再来一次模型跃迁更重要。
1.3 开发者持续交付控制平面、文件原生知识系统与编程运行框架 (🡕)¶
今天的构建活动最强的地方，是那些让智能体工作可检查的产品界面。相比泛化 copilot，最具体的产物是指挥中心、repo 原生知识系统、网关，以及能暴露状态、审批节点、trace 和隔离执行的编程编排器。
u/ageniusai 分享了 《I open-sourced a self-hosted "command center" for managing multiple n8n instances. Looking for testers.》 （23 分，10 条评论），这是一个面向多个 n8n 实例的开源指挥中心。公开的 AgeniusDesk CE README 证实，它在一个仪表盘里整合了所有实例、实时错误流、按执行划分的追踪记录、token 花费跟踪、密钥处理，以及可选的智能体集群支持；截图还显示，同一个 UI 里集成了 research、code lab、models 和实例控制。
在 《What's the best agent you've built?》 （42 分，37 条评论） 中，u/Jet_Xu（得分 1）提到了 DocMason。其 README 文档将它描述为一个仓库原生应用，用于在私有工作文件之上构建本地、可追踪的知识库。配图之所以有信息量，是因为它展示了完整架构：源文档、prepare/sync 阶段、已发布的知识库，以及带 grounded composition 和执行轨迹产物的智能体运行时。
u/liviux 在 《I built a local AI coding orchestrator around LLM councils, worktrees, and fresh-context retries (fully open-source)》 （3 分，7 条评论） 中展示了相近的“把状态放到聊天之外”思路：这是一个开源编程编排器，会把工作拆成小任务单元，让每个任务单元在独立的 git worktree 里运行，并在失败后用全新上下文重试。公开的 《LoopTroop README》 证实了其中的 LLM 委员会式规划、隔离任务单元执行、Ralph 风格重试和人工审批门；生命周期图也让这一结构变得直观。
讨论要点： 即便开发者使用了前沿模型，他们的产品主张也很少是“模型很聪明”，而更多是“系统会留下凭证、隔离工作、让状态可见，并允许人类检查发生了什么”。
与前日对比： 这一主题较 2026-06-28 更强。昨天的开发者活跃度主要集中在 n8n 运维和工作流修复；今天则扩展到了仓库原生研究系统、编程智能体编排，以及围绕外部集成的可复用网关。
2. 令人困扰的问题¶
浪费 token 且会随时间退化的开放式循环¶
严重程度：高。u/Evening-Plan-7956 在 《The loop engineering trend is a financial nightmare》 （132 分，98 条评论） 中说，一个边界设得很差的编程循环，可能会不断把聊天历史和终端日志重新注入模型，直到系统“工程化地制造出一张巨额 API 账单”。u/Future_AGI 则在 《Your agent gets dumber the longer a session runs》 （5 分，18 条评论） 中从另一个角度描述了同样的可靠性问题：一旦长任务超过大约 10 步，智能体就开始重复调用工具、忘掉前面的指令，并淹没在转录噪声里。在 《Best attempts at making an agent deterministic as possible.》 （5 分，28 条评论） 中，评论者的回答是：对“确定性”唯一可行的定义，就是在非确定性的模型外层加上确定性的边界——固定 schema、显式状态机、最大重试次数、花费上限和恢复测试。当前的应对模式是总结旧轮次、裁剪工具输出、把状态移到聊天之外。这个方向依然值得做产品，因为抱怨足够具体、反复出现，而且直接关联真实成本。
有问题的现实流程不断击败干净 demo¶
严重程度：高。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!》 （54 分，17 条评论） 中说，很多企业其实并不需要 AI 智能体；他们需要的是在现有工具中修复收件箱、CRM、表格、PDF 和通话工作流。u/pranav_mahaveer 又在 《been running an AI Automation Agency for 3+ years now. here's the thing nobody tells you when you start.》 （40 分，16 条评论） 中补充说，看似“简单”的客户流程里，常常藏着口耳相传知识、各种例外和脏数据；而 u/Warm-Reaction-456 在 《I've made $100k+ building AI automations and I'll tell you what's worth building and what's a waste of money》 （30 分，38 条评论） 中则说，一个面对客户、正确率只有 80% 的智能体，哪怕只错那 20%，也可能贵到无法承受。常见权宜方案是花更多时间观察真实操作员、收集丑陋的真实样本，并让第一版以人工审查优先。这让这种挫败感在商业上非常重要：人们反复花钱，去发现同一个范围界定错误。
一旦智能体接触真实系统，生产控制仍然太弱¶
严重程度：高。u/NowHaraya 在 《agent eval latency added 18 minutes to our CI. how are you running this without killing dev velocity?》 （17 分，14 条评论） 中报告说，一个阻塞式评估闸门把 CI 的 p99 时长从 6 分钟推到 24 分钟，已经足以让工程师为了攒批量改动而放弃持续交付。u/Common_Dream9420 则在 《AI agents took a real-world action I didn't approve. Here's what I'm building to fix it.》 （7 分，17 条评论） 中说，一个供应商外联智能体差点因为 CRM 数据过期，把合同修订发给了错误联系人，而线程最终收敛到外部审批队列、新鲜度检查、凭证包和影响半径限制这些修复思路上。u/percoAi 又在 《What breaks when AI agents move from demos to production?》 （5 分，22 条评论） 中把同样的担忧继续展开：演示只能证明智能体有一次把任务做完的能力；生产系统还需要幂等键、审批历史、重试策略，以及人类可读的运维可解释性。今天的权宜方案是定制闸门、暂存表、影子模式和人工审批，这说明控制平面这一层仍然建设不足。
3. 人们期望的功能¶
智能体真正能写入、且人类可审计的记忆¶
这是数据集中最明确的显式需求之一。在 《human-auditable memory for agent is my point of failure》 （6 分，10 条评论） 中，u/cheetosarered 说，不管是 ChatGPT 还是 Gemini 方案，只要智能体不能把角色笔记或合同偏好记忆追加到一个操作员可检查的可审计位置上，整套系统就会崩掉。这个需求并不抽象，而是非常实用：用户已经清楚知道自己想要什么产物——可写入的记忆、可见的记录，以及适合企业使用的权限控制。它的情绪张力也很强，因为让人沮丧的不是模型质量，而是某项能力在宣传里存在、到执行时却消失。机会：直接。
看起来像真实用户、还能自我维护的 eval¶
多条线程都指向了同一缺口。u/gojosoju 在 《The agent works fine in development but fails on real user phrasing. How are you closing this gap?》 （17 分，9 条评论） 中报告称，开发者自己写的查询表现大约有 94%，但真实用户措辞一来就掉到约 71%；而 u/Only_Midnight_8557 则在 《we have ~340 eval scenarios. ~80 of them never flag anything. how are you pruning your eval set?》 （17 分，12 条评论） 中说，340 个评估场景里，大约 80 个已经 6 个月没报出过任何问题，另有 40 个则一直在抓同一种失败模式。在 CI 线程里，u/NowHaraya 和评论者希望的是更小的阻塞式 smoke suite、按变更区域 gating，以及把生产 trace 提升进测试集，而不是每次 commit 都为所有场景付全价 (《agent eval latency added 18 minutes to our CI. how are you running this without killing dev velocity?》) （17 分，14 条评论）。这是一个很实际的需求，而且用户已经勾勒出了清晰的工作流。机会：直接。
能预览动作、要求批准并留下凭证的控制平面¶
最常被提到的平台愿望并不是“更好的聊天 UI”。在 《Describe your dream AI platform》 （5 分，32 条评论） 中，评论者说，他们理想中的平台应该知道自己能碰哪些系统、在高风险写操作前先预览、在合适节点请求批准，并留下可重试或可回滚的状态。u/Common_Dream9420 在 《AI agents took a real-world action I didn't approve. Here's what I'm building to fix it.》 （7 分，17 条评论） 中把同样需求具体化：面对 CRM 过期导致的错误外联，提出的新鲜度检查、凭证包、收件人预览，以及对审批与最终发送分开记录。现有开发者已经在用 AgeniusDesk CE、LoopTroop 和 AgentSpan 这类项目来回答这个问题，所以这是一个竞争已经不算空白的机会。机会：竞争型。
面向智能体与工作流的共享集成层¶
u/Fearless-Role-2707 在 《I got tired of rebuilding the same integrations in every n8n AI workflow》 （12 分，6 条评论） 中说，反复搭建 HTTP 节点、凭证、重试和 API 特定逻辑，已经在每个 n8n 工作流里被重做了一遍，这也是他们做 AgentSpan——一个位于多种服务前方的统一网关——的动机。公开的 AgentSpan README 又把这一主张扩展为：一个可自托管的 Rust 网关、MCP server、SDK、缓存，以及大量平台连接器。对已经切身体会过集成税的开发者来说，这是非常实用的需求；但它比审批/控制平面需求更窄，因为它主要面向高阶用户和运维者。机会：竞争型。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| n8n | 工作流自动化 | (+) | 触发器、分支、重试和面向操作员的工作流都很可见；今天许多具体构建都以它为中心 | 仍然需要显式的幂等防护、审批设计和更强的生产控制 |
| OpenAI models / Chat Model nodes | LLM | (+/-) | 多个工作流都用它做分类、对话、规划和客户交互 | 只要面向客户的路径里输出出错，团队就会觉得成本高到足以砍掉部署 |
| Airtable | CRM / 结构化存储 | (+/-) | 适合保存 welcome sent、visit status、follow-up date、property media 这类显式线索字段 | 一旦智能体据此行动，过期记录就会直接变成安全风险 |
| Supabase | 数据库 / 认证后端 | (+) | 为健身房 check-in MVP 提供了轻量后端和实时订阅检查 | 评论者仍在质疑整个工作流是否足够安全，能否承受生产延迟和失败处理 |
| Google Sheets | 轻量运维存储 | (+/-) | 适合日志和快速原型 | 大家反复批评它对严肃生产工作流来说太慢或太脆弱 |
| Git worktrees | 开发方法 | (+) | 能隔离编程智能体工作、保持主 checkout 干净，并让重试更安全 | 工作区隔离并不是安全沙箱 |
| Human approval gates | 治理方法 | (+) | 大家普遍把它用于外发消息、生产写入和高风险状态迁移 | 会拖慢吞吐，而且如果凭证设计不清晰，作用仍然有限 |
| Gateways / harnesses / control planes | 基础设施方法 | (+) | 减少重复集成工作、把状态留在聊天外、暴露 trace，并约束重试 | 会增加系统复杂度，而且目前仍由从业者零碎地自行搭建 |
总体来看，当技术栈让控制面更清晰，而不是假装自主性已经消除了工程需求时，满意度最高。反复出现的方法是：让模型去解释混乱输入，然后在任何昂贵或外部动作发生前，把执行交给确定性的状态检查、类型化输出、审批门或有边界的工作流。
最清晰的迁移模式，是从“一条很长的智能体聊天”转向有运行框架的系统：用 git worktree 替代脏会话、用外部状态替代整段转录回放、用控制平面或网关替代在每条流程里手工接同一批 API。竞争格局也不再只围绕原始模型对比；提供商波动、价格变化、可追踪性和集成开销，已经成了同样重要的采购标准。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Automated Gym Check-in System | u/Charming_You_8285 | 使用二维码 Web app 和工作流后端验证会员资格并记录入场 | 用更快的会员核验流程替代健身房前台人工 check-in | Next.js PWA、n8n、Supabase、Google Sheets、barcode-scanner node | Alpha | 帖子, 仓库, gist |
| AI real estate sales assistant | u/Jazzlike_Power_6197 | 处理线索接入、房源匹配、预约看房、跟进提醒和 CRM 更新 | 为销售团队提供一个有边界的助手，处理重复性的线索筛选和排期 | n8n、OpenAI、Airtable、WhatsApp、Gmail、Google Calendar | Alpha | 帖子, 跨帖 |
| AgeniusDesk CE | u/ageniusai | 集中管理多个 n8n 实例，提供错误流、trace、代码编辑、密钥和可选智能体支持 | 为工作流运维者提供一个统一位置，查看自动化集群哪里坏了 | Python、Docker、OpenTelemetry、n8n、可选 LangGraph/PydanticAI 支持 | Beta | 帖子, 仓库, 演示 |
| DocMason | u/Jet_Xu | 把办公文件编译成本地、可追踪的知识库，用于深度研究 | 让私有文件研究比对扁平文本直接聊天更可审计 | Repo 原生知识库、Codex/Claude Code 运行时、本地解析流水线 | Alpha | 线程, 仓库 |
| LoopTroop | u/liviux | 把编程 ticket 转成 PRD、beads、隔离 worktree 运行和 fresh-context 重试 | 让长时间编程智能体任务变得可检查、可恢复，而不是脆弱地塞在一条聊天里 | 本地 GUI、LLM councils、git worktrees、OpenCode | Alpha | 帖子, 仓库 |
| AgentSpan | u/Fearless-Role-2707 | 在智能体与多个外部服务之间放置统一网关 | 把每条工作流里的重复 API 接线、凭证、重试和连接器逻辑抽离出来 | Rust gateway、REST API、MCP server、SDK、dashboard | Beta | 帖子, 仓库 |
| WhatsApp Priority Message Classifier | u/Intelligent-Play-361 | 把传入的 WhatsApp 消息分类为高或低优先级，并路由 Gmail 通知 | 提供一个由初学者构建、范围狭窄但可检查的消息分流智能体示例 | n8n、OpenAI、Structured Output Parser、Gmail、WhatsApp | Alpha | 帖子, 仓库 |
- 阶段 —— 项目当前所处的位置：Shipped（已上线/已投入生产）、Beta（可用但尚不完整）、Alpha（早期原型），或 RFC（想法/提案，尚无可运行代码）
- 技术栈 —— 项目建立在其上的语言、框架、模型或服务
- 解决的问题 —— 推动这项构建出现的具体痛点或缺口
- 链接 —— GitHub 仓库、项目站点、演示、博客文章，或项目所在的其他位置
健身房 check-in 系统很好地说明了 Reddit 会奖励具体的运营细节。公开 README 证实，其前端是一个 Next.js PWA，后端是 n8n 工作流；而评论线程对原先 2–6 秒审批时间的质疑足够强烈，以至于 OP 又贴出了一张更新后的执行截图，显示现在的运行已经降到亚秒级和约 700ms。
WhatsApp 分类器的分数较低，但它的配图让架构足够可审计：WhatsApp 触发器接入一个 AI 智能体，再接结构化输出解析器、条件分支、等待步骤，以及两条 Gmail 路径。这正是数据集中其余部分反复推荐的那种有边界、可检查的智能体设计。
AgeniusDesk CE、DocMason、LoopTroop 和 AgentSpan 都指向了同一种更高层次的构建模式：从业者不再只是构建执行任务的智能体，他们还在构建围绕它们的“操作系统”。AgeniusDesk 把工作流集群的错误流和 trace 集中起来；DocMason 把本地文件变成受治理的证据层；LoopTroop 把长时间编程任务拆成可审查的 beads，并配 fresh-context 重试；AgentSpan 则把重复的服务集成压缩进一个网关。
房地产助手和 WhatsApp 分类器则展示了同一光谱的更窄一端。两者都尽量把范围绑定在一条重复性沟通流程上，能用结构化字段时就不用自由文本记忆，并让操作员能精确看到工作流在哪里分叉。反复出现的构建模式是：最有说服力的项目，会围绕模型打包控制面，而不是要求模型本身成为整个产品。
6. 新动态与亮点¶
供应商依赖本身成为可见的风险信号¶
u/shanjairaj_2000 用 《GPT 5.6 Sol meets the same fate as Claude Mythos. What is happening??》 （102 分，58 条评论） 论证：完全依赖前沿模型 API 的团队，正暴露在访问限制、价格变化和路线图不稳定之下。即便那些反驳 OP 细节的评论者，也依旧认同一个更窄但关键的观点：提供商依赖是一种负担，而本地或开放模型 fallback 越来越成了一种韧性策略，而非意识形态立场。
开源开发者正在把智能体基础设施变成公开产物，而不只是 demo¶
最强的开发者帖子并不是模糊的 showcase。DocMason、LoopTroop、AgeniusDesk CE 和 AgentSpan 都提供了公开仓库、截图和文档，展示智能体周边控制层的做法：文件来源、规划 councils、隔离 worktrees、trace、网关和审批界面。这一点之所以值得注意，是因为它把讨论从“什么提示词好用？”推进到了“围绕模型的哪种操作系统正在变得可复用？”
社区的“dream AI platform”愿望清单，主要是治理与连续性，而不是更大的聊天窗口¶
在 《Describe your dream AI platform》 （5 分，32 条评论） 中，最高信号的回复想要的是结构化记忆、动作预览、审批门、凭证、回滚状态，以及一个能把 canon、drafts、决策和待办任务区分开来的项目大脑。这与 《human-auditable memory for agent is my point of failure》 （6 分，10 条评论） 紧密呼应：其中未被满足的需求，是一个能把状态写入可审计记忆界面、而不是把状态关在黑箱里的智能体。
7. 机会在哪里¶
[+++] 面向执行动作型智能体、以审批优先的控制平面 — 证据来自 CRM 过期引发的供应商外联惊险事件、生产控制平面线程、dream-platform 愿望清单，以及 AgeniusDesk、LoopTroop 这类开发者产物。最强需求是：系统能预览动作、验证新鲜度、在合适边界请求批准，并留下凭证、回滚状态和审计日志。
[+++] 内嵌于现有渠道、契合工作流的自动化 — 多条高互动线程都在强调，真正的钱仍然在 email、WhatsApp、CRM、表格和 PDF 里的痛苦交接修复上，而不是卖一个通用智能体外壳。这一信号很强，因为同样的模式同时出现在咨询建议、代理机构复盘，以及房地产助手、健身房 check-in 流程和 WhatsApp 分类器等具体构建里。
[++] Eval 路由与场景管理工具 — CI 延迟、陈旧场景和真实用户措辞三类线程都指向同一需求：更小的阻塞式测试集、按变更区域 gating、把生产 trace 提升进测试，以及更好地裁剪长期失效的场景。这是中等机会，因为问题清晰且紧迫，但买方范围比更广泛的控制平面市场要窄。
[+] 共享网关与外部状态运行框架 — AgentSpan、LoopTroop 以及那几条讨论上下文漂移的线程都在主张：把状态留在聊天之外，并减少重复的服务接线。这一信号仍处于浮现阶段，而非主导叙事，但它在开发者仓库和运维抱怨中都很一致。
8. 要点总结¶
- 今天 Reddit 上最可信的一条规则仍然是：先让工作流契合，再加智能体。 得票最高的实用线程都在说，真正的价值来自修复团队已经在用的渠道中的痛苦交接，而不是强行给他们塞一个新的 AI 界面。(来源)
- 人们评价自主循环时，看的越来越不是“它会不会写代码”，而是成本、漂移和重试行为。 Reddit 互动最高的 loop 线程，本质上是在反对无边界递归；旁边的线程则持续要求外部状态、裁剪上下文和确定性的运行框架边界。(来源)
- 控制面正在成为一个独立的产品类别。 AgeniusDesk、DocMason、LoopTroop 和 AgentSpan 都不是把模型当成整个系统，而是在其外层打包 trace、知识边界、隔离工作或共享网关。(来源)
- 现实世界的评估仍然与真实情况不匹配。 用户报告称，开发者自己写的查询和真实用户措辞之间有 23 个点的差距，而且膨胀的 eval 套件已经不再配得上它们的算力成本。(来源)
- 最明确的未满足需求，不是另一个前沿模型，而是可审计的动作与记忆。 人们想要审批队列、凭证、回滚状态，以及自己能检查的可写记忆，尤其是在保密或企业工作流中。(来源)