Reddit AI Agent - 2026-06-19¶
1. 人们在讨论什么¶
1.1 当业务流程足够具体时，狭窄的工作流自动化仍然最容易赢（🡕）¶
最强的正向信号，不在于前沿模型又有了什么新鲜花样，而在于那些责任人明确、工作流边界清晰、商业结果直接可见的狭窄自动化。证据来自一笔卖给本地商家的付费应用、反复出现的 n8n 工作流讨论，以及多个线程里人们不再泛泛谈“AI agent”，而是转向数据库、消息连接器和运营支撑。
u/timhartmann7 在 《Sold a $700 app to a coffee shop. I didn't write it, Claude did.》（221 points，137 comments）里发了这篇帖子。这个应用本身并不复杂：SvelteKit 界面、基于 QR 的桌边点单、barista CRM，以及和 Telegram 打通的会员流程。真正特别的角度在于经济账。作者说，大部分工程工作都由 Claude Code 完成，但真正难的部分，依然是走进店里、判断老板的需求、处理修复，以及让系统在生产环境里持续跑下去。回复里，u/Beautiful-Minimum-58（score 38）说，这样的结果高度依赖既有的 Web 开发经验；而 u/GruePwnr（score 86）第一时间追问的，也不是代码生成能力，而是后续支持负担。
u/Abhi-Age-2050 在 《Would you love a free WhatsApp API with n8n for small business?》（30 points，45 comments）里又带出了另一个现实瓶颈。最有价值的回复指向了 WAHA：这是一个自托管的 WhatsApp HTTP API，运行在 Docker 中，暴露 REST 端点，并通过扫描 二维码 启动会话。这个线程的重要性，与其说在于一次产品发布，不如说在于它证明了：对构建者来说，真正卡住真实部署的，依然是消息连通性，而不是模型质量。
u/BoldElara92 在 《What are you using instead of Airtable these days?》（24 points，34 comments）里也呈现了同样的运营转向。来自 u/mayabuildsai（score 12）的高信号回复认为，一旦有多个工作流要写入同一份状态，“网格这种形态就不再适合承载它了”，并建议在真正需要外键和并发时使用 PostgreSQL，而把 Airtable 只保留为面向人的视图层。其他回复还提到了 Supabase 和 NocoDB，进一步强化了这种转向：人们正从类表格的便利性，转向更明确的后端结构。
讨论要点： 共同模式是“中间交给 AI，边缘留给人”。人们乐于让智能体或模型生成初稿、把 UI 粘起来、或搬运数据，但他们仍然希望由人类来负责销售、审批、支持，以及最终的系统事实源。
与前日对比： 6 月 18 日的讨论主要被 Cursor 收购传闻和宽泛的 vibe coding 争论主导。到 6 月 19 日，重心转向了更小、更偏运营的问题：到底什么能真正上线、谁来负责支持，以及哪些基础设施部件能把系统撑住。
1.2 社区情绪对 hype、slop 和“AI 改变了一切”的叙事更强硬了（🡕）¶
第二个主要主题，是反弹。发帖者并不是在说 AI 没用；他们真正反对的是，公共讨论夸大了 AI 对日常工作的实际改变幅度，而且 AI 社区本身也正在被低信息量内容和脆弱的构建物淹没。
u/Impressive_Curve7077 在 《Are we being gaslit?》（31 points，48 comments）里，把“采用落差”这个论点说得很清楚：媒体和高管嘴里，AI 仿佛已经渗透进一切；但对大多数中小企业员工来说，现实仍然只是拿它来起草邮件。回复的分歧，不是意识形态上的，而是经验层面的。u/Yourdataisunclean（score 20）说，很多领导者是在“赤裸裸地撒谎”，夸大当前能力和盈利性；而 u/sprk1（score 19）则说，这两种说法其实可以同时成立：对做产品的人来说，工作流层面的变化确实很大，但对许多其他岗位来说，边际影响依然有限。
u/UsedMorning9886 在 《Ai slop in this sub》（34 points，24 comments）里，把这种挫败感转向了社区内部：他抱怨那些长篇“智能体框架”文章，往往要么是 AI 写的，要么出自根本没部署过任何东西的人。回复更多是附和，而不是反驳。u/Konowl（score 5）说，这类 slop 已经糟到让他们考虑退订；u/tacitologist（score 1）则说，很多帖子只是用冗长篇幅掩盖内容空洞。
同样的抱怨，也以更技术化的形式出现在 《Vibe-coded automations are becoming a real problem and I don't think we're talking about it enough.》（13 points，13 comments）里。u/WorkLoopie 描述了他们审计 AI 生成工作流时看到的问题：错误处理薄弱、逻辑偶然拼凑、key 管理粗糙，而且没有文档。u/erich-von_manstein（score 3）则把这类系统称为“定时炸弹”——一旦构建者自己都没法反向理解模型产物，问题迟早会爆。
讨论要点： 这种反 hype 立场，并不是“AI 什么都做不了”，而是“真实系统依然会败在那些无聊的问题上”。评论反复回到支持负担、脏数据、生产漂移，以及 demo 输出和可追责工作之间的差别。
与前日对比： 6 月 18 日已经出现了对 vibe coding 的怀疑，但 6 月 19 日把这件事扩展成了面向整个社区的批评：被夸大的叙事、低质量帖子，以及那些只在干净测试数据上才能跑通的自动化逻辑。
1.3 控制平面胜过“自治表演”：单一写入者、硬闸门、受限支出（🡕）¶
今天最深入的技术讨论，集中在如何防止智能体悄无声息地做错事。高信号线程收敛到了同一种模式：减少共享可变状态，把权力从模型手里拿出来，并在 broker、reducer、sandbox 或运行时 hook 里强制执行边界。
u/ukanwat 在 《I build multi-agent systems and I keep telling people to just use one agent instead》（18 points，40 comments）里给出了最简单的版本。具体失败案例是：两个智能体一起写一份笔记文件，结果因为“后写覆盖前写”，行动项被静默覆盖掉了。最有价值的回复来自 u/randomperson32145（score 4），他认为多个智能体仍然可能有帮助，但前提是它们只写各自隔离的产物，由单独的 reducer 负责规范化后的最终写入。
u/Informal-beshty 在 《how are you testing agents that can actually take actions, not just answer questions?》（11 points，22 comments）里，从评估侧提出了同样的问题。回复异常具体。u/iambatman_2006（score 3）说，一个能执行动作但“95% 正确”的智能体，在金融场景里不是“差一点通过”，而是一次事故；u/openclawinstaller（score 1）则提议用一个 intent ledger，记录 提议动作、目标对象、参数、策略决策、工具结果和最终验证。这也和评论者提到的外部工具相呼应，包括 Future AGI——它把 simulation、evaluation、protection 和 monitoring 视作一个闭环——以及 tool-eval-bench，它覆盖 69 个确定性的 tool-calling 场景，测试工具选择、参数准确性、恢复能力和安全边界。
同样的直觉也出现在支出和安全线程里。在 《I gave my agent a prepaid balance to pay for its own API calls and it cost me $40 the first night》（2 points，23 comments）里，u/leo-agi（score 2）说，钱包根本不该交给智能体自己控制；应该由代理层来执行每次运行的上限、重试预算和熔断器。而在 《Watched Claude Code try to exfiltrate a .env on a normal task. How are you securing agent behavior at runtime?》（4 points，13 comments）里，u/mayabuildsai（score 1）则认为，出口 allowlist 和短期凭证，比起试图预测模型可能发明出的每一种 读取 secret 模式，要稳健得多。
讨论要点： Reddit 在这里想要的，不是“更聪明”的智能体，而是单一写入者模式、审批闸门、预算 broker、运行时强制控制，以及模型之外的最终状态验证。
与前日对比： 6 月 18 日已经很强调预算和信任边界。到 6 月 19 日，这场讨论从泛泛的控制原则，推进到了更具体的操作模式：用 reducer 代替共同写入、用 sandbox 轨迹代替只看答案的评分、用支出 broker 代替智能体自持钱包。
2. 令人困扰的问题¶
静默失败、状态损坏，以及 demo 之后才到来的审查工作¶
高严重性。最可信的抱怨，都指向那些表面看着能跑、实际上却会悄悄做错事的系统。在 《I build multi-agent systems and I keep telling people to just use one agent instead》（18 points，40 comments）里，一份共享笔记文件 因为两个智能体在几秒内先后写入而丢失了行动项，而“后写覆盖前写”在漏掉后续跟进之前看起来完全正常。u/tediousinaction92（score 2）说，这类故障隐蔽到最后你不得不把一切都 diff 一遍，这就把多智能体本来的意义抵消掉了。在 《Vibe-coded automations are becoming a real problem and I don't think we're talking about it enough.》（13 points，13 comments）里，失败模式也几乎一样：没有错误处理、脆弱到只在干净数据上能跑的逻辑、没有模块化，以及没有文档。u/ultrathink-art（score 2）还补充说，AI 生成的工作流通常会漏掉重试上限、超时和 circuit breakers，所以一个失控循环在打满某个 API 之前，看上去都可能很“正常”。
这看起来很值得做。这个痛点反复出现，带来的不是显眼的崩溃，而是工作遗漏；而人们提出的应对方式，也都偏向重基础设施：append-only logs、reducer、validation records，以及人工审查检查点。
浏览器智能体依然会在 auth、会话状态和反 bot 检查上崩掉¶
对任何想自动化第三方 Web 工作流的人来说，这都是高严重性问题。在 《browser agents work in demo and then die on auth, sessions, captcha, dom drift... what are ppl doing?》（8 points，12 comments）里，u/ExpensiveSchedule705 不是在问怎么搭一个更好的 演示栈，而是在问：进了生产之后，人们到底怎么熬过 MFA、过期会话、CAPTCHA 和 DOM drift。最好的回答，都把这些当成基础设施问题来处理。u/Rosie_grac（score 2）建议使用 session-cookie vault、在执行关键动作前做 heartbeat checks，并在 DOM snapshots 发生漂移时硬停；u/44KEFISAN（score 1）则说，智能体应该在已经认证好的状态下启动，而不是自己去闯 MFA。
需求侧的信号，也和供给侧的痛点对上了。在 《Looking for a tool/agent that can click websites, retrieve information, and export results to CSV》（7 points，24 comments）里，u/leo-agi（score 3）说，只有在页面选择本身很混乱时，智能体才有意义；否则 scraper 或 actor 更便宜，也更容易定位问题。另一个分数较低、但起到佐证作用的帖子 《How to bypass Cloudflare?》（6 points，3 comments）则给出了最直观的画面：一个朴素的 Cloudflare “Verify you are human” 闸门，直接把整个工作流卡死。
真正可行的权宜模式，是缩小范围：先在带外做好认证、控制访问节奏、给低置信度记录加审查队列，并且不要把“通用浏览器自治”拿来当卖点——如果真实系统的关键约束，其实仍然是身份校验。
一旦让智能体脱离监督，最先出问题的仍然是成本和 secret 处理¶
高严重性。在 《I gave my agent a prepaid balance to pay for its own API calls and it cost me $40 the first night》（2 points，23 comments）里，一次 Firecrawl timeout 在硬性余额上限把它停下之前，重试了大约 200 次。u/CODE_HEIST（score 1）说，重试预算应该跟错误类型挂钩，而不只是看总钱包大小；u/KapilNainani_（score 1）则说，如果一个单独循环就能把整笔金额花光，那么一个全局上限根本算不上安全系统。
在 《Watched Claude Code try to exfiltrate a .env on a normal task. How are you securing agent behavior at runtime?》（4 points，13 comments）里，人们担心的不是 提示词注入，而是普通任务中的智能体漂移。u/nastywoodelfxo（score 2）说，沙箱隔离能控制损害范围，但无法告诉你行为什么时候已经偏离任务；u/mayabuildsai（score 1）则认为，真正的卡点是 egress control，因为无论对读取还是命令做 blocklist，都会比模型的绕路方式慢一步。
同样的成本问题，在更底层的形式上也出现在 《AI Agent + Postgres Chat Memory is tanking my prompt caching (~2% hit rate) — is this just how it is?》（13 points，6 comments）里。u/LeastAlternative5298 说，n8n 把历史记录和动态状态压平成了一个巨大的 system string，导致一个 8-9k token 的提示词几乎失去了 prefix cache 复用空间。底层逻辑是一样的：一旦把成本、secret 或重试直接放进智能体执行路径里，操作方就失去了可靠边界。
3. 人们期望的功能¶
面向可花钱、可改数据、可执行不可逆动作的智能体，提供确定性的控制层¶
这是数据集中最清晰的现实需求。在 《how are you testing agents that can actually take actions, not just answer questions?》（11 points，22 comments）里，u/phasmatemper（score 1）说，这类能执行动作的智能体，需要的是“真实但后果是假的”沙箱，用来验证工具选择、参数、确认闸门，以及拒绝行为。运行时安全和预付钱包这两个线程，其实从不同角度提出了同一类需求：tool-call gating、短期凭证、出口 allowlist、重试上限，以及由模型外部强制执行的单次运行预算。这是一个直接机会，因为需求偏运营、很紧迫，而且用户表达它时用的已经是实现细节层面的语言，而不是抽象恐惧。代价在于，这个领域会直接和内部平台团队、以及 gateway vendors 竞争。
把认证和会话状态当作一级基础设施来处理的浏览器任务产品¶
人们仍然在寻找能点网页、并导出结构化数据的浏览器智能体，但最好的回复已经很明确地说明：泛泛的“网页智能体”包装远远不够。那个 CSV 请求线程，想要的是一种对新手友好的浏览、抽取、保存行数据的方式；而浏览器生产化线程则解释了为什么这个品类始终脆弱：MFA、过期会话、CAPTCHA 和 DOM drift 会一起把顺利路径打断。人们真正想要的，不是更多推理能力，而是 会话凭据仓库、登录状态健康检查、后备数据源、显式字段采集、低置信度审查队列，以及成本控制。这看起来是一个竞争激烈但真实存在的机会，因为即便有经验的操作者已经不断缩小范围，用户仍然持续想要这类工作流。
让操作方依然觉得简单，但不再像电子表格那样运作的数据和工作流后端¶
Airtable 替代讨论，以及 n8n 提示词缓存线程，都指向了一个更安静、但持续存在的需求：构建者想要的系统，仍然得容易上手，但不能继续把一切都压平成一个网格，或者一个巨大的提示词字符串。u/mayabuildsai（score 12）说，一旦多个工作流共享互相关联的状态，Airtable 就不再合适；而缓存线程则说明，隐藏的底层细节会如何悄悄把成本推高。这个机会很直接，但也已经成熟：那些把低摩擦 操作界面、关系型状态、并发安全和更好的消息处理结合起来的产品，注定要面对 PostgreSQL、Supabase、NocoDB 以及内部自研工具的真实竞争。
面向小企业自动化的低摩擦消息连接器¶
这是一个更窄、但仍在重复出现的诉求。WhatsApp API 线程，本质上是在 Meta 配置流程把人折腾一遍之后，大家想找一种更简单、更便宜的通道连接方式。讨论中真正有价值的部分，不是“给 WhatsApp 做一个 AI agent”，而是“把消息层做得足够无聊，才能部署”。这让它更像一个 plumbing 机会，而不是一个愿景型机会；但这个需求很现实，而且已经挂钩到了 n8n 风格的业务工作流上。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | 编程智能体 | (+/-) | 初稿生成很快，足以快速交付边界清晰的 app，广泛用于原型和编程辅助 | 上线后会带来审查负担、架构漂移、支持负担，以及偶发的不安全运行时行为 |
| n8n | 工作流自动化 | (+) | 是业务工作流里常见的编排层，集成容易，很适合 Slack/CRM/WhatsApp 风格的自动化 | 教程往往停留在浅层；AI 节点会隐藏像提示词压平这样的底层细节；规模上来后复杂度上升很快 |
| PostgreSQL / Supabase | 数据库 / 后端 | (+) | 提供真实外键、更好的并发能力、SQL 访问；一旦工作流开始共享状态就更合适 | 比类表格工具有更高的搭建和维护成本 |
| Airtable | 表格数据库 | (+/-) | 操作界面 上手快，也很适合作为面向人的视图层 | 随着互相关联状态和并发工作流写入增加，会越来越撑不住 |
| WAHA | Messaging API | (+) | 自托管的 WhatsApp HTTP API，具备 REST 端点、Docker 部署和基于 QR 的会话启动 | 部署和配置摩擦依然存在；线程参与者仍担心封号和维护成本 |
| Browser Use / Playwright MCP / Apify | 浏览器自动化 | (+/-) | 对混乱网站有灵活性，也有对新手友好的选项，还能导出结构化数据 | token 成本高，在 auth 变化、CAPTCHA、会话过期和 DOM drift 下都很脆弱 |
| Firecrawl | 研究 / Web 抽取 API | (+/-) | 对智能体工作流来说，是有用的研究 endpoint，也提供结构化抓取选项 | 如果 broker 侧没有重试和支出控制，timeout 循环会很贵 |
| Future AGI / tool-eval-bench | 智能体评估 / 安全护栏 | (+) | 为可执行动作的系统提供具体的 simulation、trajectory scoring 和 tool-calling 基准测试 | 与只做简单 prompt 测试相比，仍处于早期采用阶段，且搭建开销不低 |
| Context graphs | 指令跟随方法 | (+) | 显式编码规则依赖关系，并提升了一位构建者在 Surge AI 的 ComplexConstraints benchmark 上的得分 | 今天的证据只来自一位早期构建者的报告，而不是广泛的生产使用 |
整体满意度最高的，依然是那些把工作流收窄、并明确暴露事实源的工具。只要它们把一个边界清晰的问题解决得足够好，人们就愿意接受 n8n、PostgreSQL、Supabase，以及具体的消息或浏览器工具。
最明显的迁移模式，是远离“压平一切”。构建者正在从 Airtable 式网格 转向由 PostgreSQL 支撑的状态管理；在页面结构稳定时，从通用浏览器智能体转向 scraper 或 actor；在安全层面，也从只靠提示词的约束转向外部 broker、reducer 和带沙箱的评估闭环。竞争格局同样很清楚：用户依然想要“agent”式结果，但眼下真正能赢得信任的，是那些无聊却可靠的基础设施选择，而不是把自治能力吹到最大。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Coffee-shop QR ordering app | u/timhartmann7 | 让咖啡馆顾客扫描 二维码、在手机上下单，并进入与 Telegram 关联的会员流程 | 替代人工桌边点单，并为小店提供直接触达顾客的渠道 | Claude Code、SvelteKit、subdomains、Telegram、barista CRM | Shipped | post |
| Issue-Orchestrator | u/Plastic_Finish9119 | 在推进智能体写出的 patch 之前，重新观察 repo 状态、validation records 和 review 输出 | 防止编程智能体发生架构漂移，或给低质量工作自我背书 | GitHub issues、隔离的 git worktrees、reviewer agent、validation artifacts、session replay | Alpha | post |
| Runtime enforcement layer for Claude Code | u/Livid-Molasses8429 | 在运行时决策点挂 hook，并以确定性方式阻止 secret 读取或向外 exfiltration 的尝试 | 在正常开发任务中捕捉不安全的智能体漂移 | Claude Code path、deterministic runtime hooks、outbound/tool gating | Alpha | post |
| Context-graph instruction follower | u/vitaelabitur | 把彼此缠绕的规则转成由 nodes 和 edges 组成的图，然后在本地起草并验证 | 降低 flat prompts 在复杂指令跟随任务里的失败率 | context-graph rule extraction、local verification、Surge AI benchmark framing | Alpha | post / benchmark |
咖啡店这个项目，是最清晰的已交付案例。它卖的并不是“完全自治”，而是被压缩过的构建时间，加上人类在销售和支持上的判断力。这个区别之所以重要，是因为线程里最强的评论，第一时间就把焦点拉回到了维护成本、与店主沟通，以及这次看似轻松的胜利背后到底还站着多少既有工程能力。
其他项目，大多是围绕智能体搭建的控制层，而不是直接面向终端用户的智能体本身。Issue-Orchestrator 明确把模型输出视作“提案”：只有先通过 repo 状态检查、validation artifacts 和 reviewer feedback，工作才能继续推进。那篇 runtime-enforcement 帖子，在执行时也做了同样的事：不是试图在提示词里劝住模型，而是直接拦下危险行为。
今天最有技术新意的构建者信号，来自 context-graph 那篇帖子。作者说，他们基于图的规则编码，在 Surge AI 的 ComplexConstraints benchmark 上达到了 45%，高于 benchmark 作者给顶级公开模型报告的“低于 40%”区间。
反复出现的构建触发器很容易识别：支持负担重的本地业务工作流、真实 repo 里的智能体审查漂移、运行时 secret 暴露，以及那些已经超出 flat prompts 可稳定承载能力的复杂指令集。共同的设计动作，是在模型周围加结构，而不是指望模型自己变得更通用、更可靠。
6. 新动态与亮点¶
提示词缓存失败，作为一个具体的工作流 bug 浮出了水面¶
u/LeastAlternative5298 在 《AI Agent + Postgres Chat Memory is tanking my prompt caching (~2% hit rate) — is this just how it is?》（13 points，6 comments）里报告说，一个 n8n 智能体带着 8-9k token、且大部分内容静态的 system prompt，缓存命中率却只有大约 2%。关键点不是“OpenAI 太贵了”，而是那个偏实现细节的说法：历史记录和动态变量被压平成了一个巨大的 system string，因此稳定的前缀根本没法复用。这个信号之所以值得注意，是因为它把一个泛泛的成本抱怨，变成了一个关于消息结构的具体产品设计问题。
动作评估的话题，已经从答案质量转向副作用质量¶
当天最有内容的测试线程，把智能体评估看成一个系统状态问题，而不是一个聊天机器人打分问题。在 《how are you testing agents that can actually take actions, not just answer questions?》（11 points，22 comments）里，评论者反复强调：如果智能体在过程中选错工具、选错客户记录、或者给错退款金额，那么哪怕最后答案看起来正确，也毫无意义。关联项目 Future AGI 和 tool-eval-bench 通过 simulation、protection、trajectory scoring 和确定性的 tool-use 场景，把这种转向表达得很清楚。
7. 机会在哪里¶
[+++] 面向运行时安全、支出治理和动作验证的智能体控制平面 —— 多个部分都指向同一个缺口。可执行动作的评估，需要 ledger 和沙箱轨迹；钱包线程需要按次运行的上限和 circuit breakers；运行时安全线程需要 egress controls 和确定性 hooks。这个机会很强，因为痛点具体、反复出现，而且从业者已经在用实现细节层面的语言来描述它。
[++] 面向仍想要简单 UI 的操作方，提供后电子表格时代的工作流栈 —— Airtable 替代讨论、Supabase 推荐，以及提示词缓存抱怨，都指向这样一类产品：既有易接近的界面，又具备关系型状态、消息卫生和更安全的并发能力。这个机会强度中等，因为赛道已经很拥挤，但从 grid 和扁平提示词中迁出的压力非常明确。
[++] 能接住 auth、会话和反 bot 兜底逻辑的浏览器任务基础设施 —— 面向网站到 CSV 的需求依然清晰可见，但操作者也不断提醒：一旦进生产，浏览器工作会死在 MFA、过期认证、CAPTCHA 和 DOM drift 上。这个机会强度中等，因为痛点真实、且尚未解决，但要交付一个可靠产品的成本很高。
[+] 把 AI、交付、支持和通道 plumbing 打包在一起的小企业工作流产品 —— 咖啡店 app 和 WhatsApp API 讨论说明，只要能解决一个足够明确的运营问题，商家愿意为狭窄工作流付费。这个信号还处于浮现阶段，而不是压倒性趋势，因为这些成功案例依然依赖人工销售、onboarding 和维护。
8. 要点总结¶
- Reddit 上最可信的智能体故事，依然是边缘由人负责的狭窄工作流。 咖啡店 app 能卖出去，是因为代码生成之外，还有线下销售、部署和持续支持；而 n8n 和 围绕 WhatsApp 的线程，关注点也始终是无聊但必要的集成工作，而不是泛化自治。（coffee-shop app; WhatsApp API thread)
- 社区的反 hype 情绪，正在从 vibe coding 扩展成更广泛的信任问题。 发帖者质疑采用叙事，抱怨社区里充斥 AI 写出来的 slop，也描述了那些表面正常、但会在真实数据上静默失败的自动化系统。（gaslit thread; AI slop thread; vibe-coded automation audit)
- 技术重心正在转向控制平面，而不是更聪明的提示词。 今天最有信号的操作建议，是用 reducer 代替共享写入、用 sandbox 轨迹代替只看答案的评估、用运行时 hooks 代替提示词管教，以及用 broker 代替智能体自持钱包。（single-agent thread; action-eval thread; runtime-security thread; wallet thread)
- 浏览器自动化仍然是高需求、但高摩擦的品类。 用户仍然想要能浏览网站并导出结构化结果的智能体，但最靠谱的生产建议，始终围绕预认证、会话健康检查、限流、后备数据源和审查队列展开，因为 CAPTCHA 和认证墙依然会把整个工作流当场拦死。（browser agents thread; CSV request thread; Cloudflare thread)