Twitter AI Agent - 2026-09-27¶
1. 大家在讨论什么¶
1.1 Harness 工程如今已是产品本身，而不再只是注脚 (🡕)¶
在 2026-09-27，最大的一组讨论把 harness 本身视为差异化关键：子代理如何协调，模型行为如何受约束，上下文如何保留，以及有多少工作能从基础模型转移到运行时层。至少有五条高信号内容支撑了这一主题，涵盖产品层面的主张、一手运行时评测，以及一门把 harness 设计视为独立学科的开源课程。
@thdxr 认为（2,535 次点赞，58 条回复，167,043 次浏览，1,005 次收藏），称 OpenCode 的效果“完全来自 harness”，而不是底层模型本身。回复没有削弱这一说法，反而让它更具体：Kit Langton 表示 OpenCode 2.5 正在移除 plan mode；thdxr 则说，这款产品正在更深入地押注 Jev，同时其实已经上线了浏览器支持，只是还需要更好地呈现出来。这里的重点是操作层面的，而非哲学层面的：人们越来越倾向于把代理质量归因于运行时的控制策略，而不只是底下接了哪个前沿模型。
@daniel_mac8 报道称（201 次点赞，26 条回复，14,834 次浏览，79 次收藏），称 Claude Code 搭配 Opus 5.5 的新动态工作流，是他用过的最佳多代理编排体验。他随后还链接了 Anthropic 的 动态工作流实用手册，其中写道，Claude 会编写一个 JavaScript 编排脚本，通过 Workflow 工具运行它，最多可同时保持 16 个代理活跃，并通过代码级分支与验证来推进，而不是只依赖主代理的上下文窗口。
@Da7_Tech 报道称（162 次点赞，53 条回复，15,637 次浏览，67 次收藏），称在使用 Droid 两个月后，他认为 harness 的重要性与模型阵容同样高。他的评测补充了少见的运行细节：缓存效率约 94%，14 天内约 70 个会话共消耗约 5.85 亿 tokens，在 Claude、GPT、Grok、Kimi、Qwen 和 GLM 系列上的表现都很强；而他的抱怨清单也主要集中在 harness 功能上，而不是模型智力：缺少长期记忆、配额耗尽后语音被禁用，以及长时思考任务过早被打断。
@RoundtableSpace 强调（44 次点赞，12 条回复，40,685 次浏览，49 次收藏），介绍了开源的 Learn Harness Engineering 课程。该仓库明确聚焦于让编程代理更可靠的环境、状态管理、验证与控制机制，而当前 README 标注其包含 14 讲、8 个项目，以及对 Claude Code、Codex、Pi 和 DeepSeek 的拆解。
@sudoingX 认为（69 次点赞，9 条回复，2,521 次浏览，70 次收藏），称即便是本地代理工作，也应该从 wrapper 之下那一层入手。他的建议是先使用 llama.cpp，检查 context window、GPU offload、KV-cache quantization、speculative decoding 和 chat templates 等参数，先弄清一次运行为什么快、为什么慢、为什么会内存耗尽，再去信任 Ollama 或 LM Studio 这样的高层 wrapper。
讨论洞察： 最有价值的回复讨论的都是运行时边界，而不是对模型的盲目推崇。大家持续追问的是：plan mode 是否只会增加噪音、浏览器工具是否真的可用、长时间运行的工作流在子代理数量增加后还能否保持有序，以及本地 wrapper 是否会让人忽视服务层到底在做什么。
与前一天相比： 2026-09-26 的讨论已经把 harness 工程当作一种日常操作层面的方法论。到了 2026-09-27，这场讨论变得更产品化，也更可复用：工作流脚本、开源课程、运行时评测，以及底层服务经验，都在把同一个理念从理论推向成文化实践。
1.2 控制器层、治理与自我改进进入可量化阶段 (🡕)¶
第二组讨论聚焦于主模型外围的部分：能阻止浪费性循环的控制器层、不是一开始就授予自主权，而是靠表现赢得自主权的治理系统，以及无需改动模型就能演进 harness 的研究。至少有六条高信号内容支撑了这一主题。
@choopyplug1 解释道（18 次点赞，9 条回复，393 次浏览，11 次收藏），讨论如何在“wrong-tool loops”烧掉前沿模型预算之前就将其掐灭。配图给出的方案是：不要让 LLM 从庞大的工具列表中自由挑选；让 Jev 给出一个有效选项或 none；每一步都重建候选工具列表；按置信度设门槛；对反复失败的循环直接终止，而不是无休止地为重试买单。
@0xRicker 认为（40 次点赞，12 条回复，2,729 次浏览，37 次收藏），称 Jev Engineering 已运行 5,400 次代理执行，其中包含 43 次 Jev 调用，且 0 次转人工。他的表述是，真正的收益并不是抽象意义上的“更高自主性”，而是日常决策中需要把人重新拉回闭环的理由更少了，尤其是在系统跨过某个评分阈值后还能自行停下的情况下。@gippp69 认为（76 次点赞、20 条回复、2,922 次浏览、62 次收藏）称，一个每月大约要做 600 个小决策的 Claude 循环，如果把决策层卸载给 Jev，成本可从约 $765/月降至约 $3.02/月。尽管具体经济性会因工作流而异，但整个数据集中反复出现的底层模式是一致的：人们越来越倾向于把控制逻辑从昂贵模型中剥离出来，而不是一味要求同一个模型思考得更深。
@arXivBangers 强调（37 次点赞、4 条回复、1,295 次浏览、22 次收藏）这篇论文 Harness as a Language：具备极致表达力的极简 Agent 框架。链接摘要称，JAZ 围绕一个递归的 invoke 原语来构建智能体，并声称在特定任务上，相比更专门的记忆与自我改进框架，能以更低成本胜出。
@beamnxw 强调（27 次点赞、15 条回复、866 次浏览、23 次收藏）The Digital Apprentice，将自主性定义为一种按技能逐步获得、而非一次性授予的能力。该论文的公开摘要提到一个方法捕获层、显式授权门，以及会转化为偏好数据的运行时纠正；这与配图所强调的渐进式自主性和推理时质量控制相吻合。
@beamnxw 还强调了（29 次点赞、10 条回复、396 次浏览、17 次收藏）RRSI，这是一个 Google Research 项目，围绕一个冻结模型演化提示词、控制流、工具、记忆、上下文管理、技能和子智能体。该仓库 README 表示，这种搜索经过正则化处理，以避免 benchmark 泄漏和过拟合；并报告称，在 Terminal-Bench、Harvey LAB、JobBench、GDPval、APEX-Agents 和工程基准上取得提升，同时相较未正则化的演化减少了 policy token 的使用。
讨论洞察： 最有分量的回复已不再把控制层当作一种玩具式优化。人们反复追问的是：控制器是否知道何时该说 none；一个可自我改进的 harness 究竟是在泛化还是在过拟合；以及这种“逐步获得的自主性”在高风险权限扩大之前，是否留下了可审计的轨迹。
与前一天对比： 在 2026-09-26，类型化决策层和 Jev 风格控制器已经是一个活跃话题。到了 2026-09-27，这场讨论进一步扩展到治理与演化：更便宜的决策路由、逐步获得的自主性，以及可自我改进的 harness，都落在了同一条时间线上。
1.3 人们评判智能体商业的标准，正在从发现转向结算与证据（🡕）¶
围绕智能体商业的讨论依然很热，但重点进一步从“发现”本身转向一项工作究竟如何完成闭环：托管、哈希、争议窗口、证据保全，以及市场是否拥有足够可信的供给，从而真正具备意义。至少有七条保留内容支撑了这一主题。
@RifdahSR_11 认为（103 次点赞、86 条回复、4,433 次浏览）称，TermiX 与 Upwork 的真正区别不在于收费，而在于结算模式。她的幻灯片把这一说法变成了一条清晰可见的流程：发布工作、报价、锁定资金、交付、验证、结算、必要时提出异议，并保留由此产生的声誉；平台更像中立基础设施，而不是一个永久性中介。
@Subit_Crypto 认为（76 次点赞、83 条回复、376 次浏览）称，关键不在于智能体能彼此对话，而在于它们能为工作拨付资金、在提交时把交付物的哈希写上链、通过争议窗口和评审小组处理纠纷，并基于已结算结果而非自报星级建立可携带的声誉。这条帖子把这一想法推进到了机器速度：如果智能体之间要彼此购买微型服务，那么这个市场的出清速度和机制化程度都必须远高于人类自由职业平台。@EClock24 认为（75 个赞，24 条回复，311 次浏览，55 次收藏）指出，发现机制、消息传递和安全性可以解释一笔交易如何开始，却解释不了当双方对过程记忆不一致时，交易该如何收场。他以 memecoin 的实时情绪数据为例，直白地点出了缺失的一环：在资金划转前先写清条款，在工作进行时保全证据，使用多模型验证器，以及在买方与服务方发生分歧时提供申诉路径。
@RifatOfficiall 认为（73 个赞，78 条回复，317 次浏览）指出，更值得关注的并不是 marketplace 页面本身，而是让 agent 连接自己的账户并直接与市场交互的那项能力。配图之所以重要，是因为它把安装和连接路径可视化了：这是一套 agent 可以接入的基础设施，不只是一个可供浏览的页面。
@Hemtee5 提供了反证（33 个赞，16 条回复，483 次浏览）指出，实际供给看起来仍比 marketplace 的注册数量所暗示的要稀薄。他的例子很直接：1 美元的全息卡之所以成立，是因为商品 listing、价格和交付物都已经定义清楚；但一旦任务变成研究这类开放式工作，瓶颈就变成是否有人愿意且有能力接单，而不只是有没有托管和结算通道。
讨论洞察： 回复者对泛泛而谈的“agent economy”口号兴趣不大，真正关心的是失败时的处理机制。他们不断追问：证据由谁保管、交付物有争议时怎么办、法庭能否处理跨系统交易，以及真正能做实际工作的 agent 究竟有多少，而不只是完成注册的数量。
与前一天对比： 2026-09-26 的讨论已经偏向身份、声誉和评估者。到了 2026-09-27，话题更明确地转向了收尾机制：交付物哈希、异议窗口、证据保全，以及名义库存与可靠供给之间持续存在的落差。
1.4 记忆与外部身份正成为一等基础设施（🡕）¶
第四个主题用同一个概念把 coding agents 和 consumer agents 连接了起来：延续性。人们希望 coding agents 能在跨工具、跨会话之间记住已经审阅过的经验，也希望 consumer agents 在外部世界中保持稳定身份，而不是每次都像一次性调用或从零开始的会话。至少有五条保留内容支撑了这一主题。
@prayag_dalal 报道称（4 个赞，8 条回复，133 次浏览）指出，Agent Beacon 可以汇集 Claude Code、Cursor、Codex 和其他 coding-agent harness 的会话历史，再把经过审阅的经验转化为可复用知识，供后续 agent 通过 MCP 或 Agent Skills 检索。这里最有价值的细节是，审阅这一步很关键：一条被保存的经验需要某种机制来判断它在什么情况下仍然适用。
@DivyanshT91162 梳理了（6 个赞，3 条回复，419 次浏览）列出了十个记忆项目，包括 projectmem、Kage、Mori、Memoir、Supermemory、Memvid、SimpleMem、Vestige、Engrava 和 Lians。他的核心观点是，更大的上下文窗口并不足够；agent 还需要经验、来源追踪，以及避免重复调用过时修复方案或失败尝试的方法。
@Musecases 认为（19 个赞，7 条回复，2,641 次浏览，14 次收藏）指出，Bland 的新方案给 Muse 带来的不只是通话功能，而是更持久的东西：一个固定电话号码。链接文章称，这个 29.99 美元/月的套餐提供美国/加拿大无限通话和短信、1 路并发通话、每小时最多 60 通、每天最多 500 通，并让电话号码本身成为一种身份基础设施，能够在反复通话中积累声誉。
@FredaDuan 估计（23 个赞，1 条回复，1,549 次浏览，30 次收藏）探讨了一个日活 1 亿的 Muse 可能需要什么。她给出的基准情境图显示，大约需要 2,500 万个在线 VM、大约 1,250 万个物理 CPU 核心、沙箱层约 0.1GW，以及在某一使用假设下推理层约 1-2GW，因此总计 3-4GW 看起来是合理的。
讨论洞察： 无论是 coding agents 还是 consumer agents，延续性都是卖点。人们希望下一次 coding 会话能继承一条经过审阅的经验，而不是再来一轮设置提示；也希望下一通电话来自同一个号码，而不是另一个一次性的 AI 声音。
与前一天对比： 2026-09-26 关于语音和 desktop agents 的讨论主要集中在可用性和产品表层。到了 2026-09-27，话题已经转向延续性基础设施：跨 harness 的记忆层、持久化电话身份，以及常驻 agent 所需的硬基础设施测算。
2. 什么让人沮丧¶
自主性总是在用户最想抽身离开的时候失灵¶
严重性：高。@Da7_Tech 报道称（162 个赞，53 条回复，15,637 次浏览，67 次收藏）表示，Droid 很适合长时间会话，但仍会在不该停下的时候停下：主配额一耗尽，语音输入就会消失；Mission Mode 还不是真正的目标模式；而 Opus 5.5 的长时深度思考运行也可能被打断，因为 harness 会把静默推理误判为没有进展。@choopyplug1 解释道（18 个赞，9 条回复，393 次浏览，11 次收藏）则从另一个角度指出了同样的痛点：昂贵的 agent 依然会选错工具、陷入循环，并在有人出手叫停之前烧光预算。@0xRicker 认为（40 个赞，12 条回复，2,729 次浏览，37 次收藏）表示，更好的控制器设计已经在一个 Jev 工作流中将人工升级处理降为零，这反而让剩余这些中断点显得本可避免。
应对方式正越来越趋同。人们会把一次运行拆成明确的模式，把小决策交给廉价控制器处理，并把“完全自主”视为 harness 应该逐步赢得并维持的能力，而不是主模型自己临场发挥出来的东西。令人沮丧的是，最后这一公里仍然很脆弱：agent 要么会为了例行收尾来打断询问，要么会反复犯同一种本可避免的工具使用错误。
值得为此构建吗？ 值得。这是围绕无人值守执行、停止/继续策略以及置信度感知控制的直接运营痛点。
记忆和指令状态仍然太容易丢失或碎片化¶
严重性：高。@Da7_Tech 报道称（162 个赞，53 条回复，15,637 次浏览，67 次收藏）表示，Droid 仍然缺少真正可编辑的记忆层，甚至连指令文件的放置位置都会导致行为不一致，直到他把所有内容统一到官方的 Factory/AGENTS.md 路径下。@prayag_dalal 报道称（4 个赞，8 条回复，133 次浏览）之所以做 Agent Beacon，正是因为人们已经厌倦了把同一个项目里的经验反复教给每一个新 harness。@DivyanshT91162 梳理了（6 个赞，3 条回复，419 次浏览）还提到，已经出现了一整波小型记忆项目，这本身就说明当前默认方案还不够用。
当前的应对模式是手动审查和外部化：把经验保存在聊天之外，让记忆保持 Git 原生或可由 MCP 寻址，并在信任一个新会话之前，先确认 harness 实际读取的是哪个指令文件。这种做法虽然有效，但也把记忆卫生重新推回给了用户。
值得为此构建吗？ 值得。这是围绕连续性、来源可追溯性和指令一致性反复出现的痛点。
市场平台仍难以证明真实供给，或在任务出问题时保全证据¶
严重性：高。@Hemtee5 提供了反证（33 个赞，16 条回复，483 次浏览）表示，注册数量并不等于真正可用的供给：他分享的截图显示“440,000 个已注册 agent”，但实际只展示出 4 个已验证的列表。@Str_kerX 认为（105 个赞，26 条回复，8,242 次浏览）表示，就连证据本身也会衰减，因为聊天记录会被清空、日志会消失，而 agent 会在有人提出争议之前就被关停。@EClock24 认为（75 个赞，24 条回复，311 次浏览，55 次收藏）表示，大多数技术栈都会解释发现和消息传递，却不会说明当双方对结果各执一词时，一笔交易该如何收场。
当前的应对模式是，把工作限制在微小且预先定义好的任务内，让交付物一目了然；或者在工作开始前，就先约定争议处理路径和证据留存链路。这总比什么都没有好，但这也说明 agent 商业化面临的仍是信任与流动性问题，而不只是 UX 问题。值得为此构建吗？ 是的。这个痛点是结构性的，会反复出现，而且与智能体市场最终能否显得可靠紧密相关。
持久语音和电话级身份很有前景，但仍然脆弱且昂贵¶
严重程度：中。@Musecases 认为（19 个赞，7 条回复，2,641 次浏览，14 次收藏）提到，持久电话号码之所以重要，是因为它能为消费级智能体提供一个用户可以回拨的稳定身份。链接文章也暴露出明显限制：只能同时接 1 通电话、仅限美国/加拿大，以及固定的每小时和每日通话上限。@FredaDuan 估计 提到（23 个赞，1 条回复，1,549 次浏览，30 次收藏），如果像 Muse 这样的产品扩展到 1 亿 DAU，基础设施需求将达到多吉瓦级；而 @Da7_Tech 抱怨（162 个赞，53 条回复，15,637 次浏览，67 次收藏）则指出，恰恰是在重度用户撞上配额墙时，语音会变得无法使用。
人们想要的不是又一个语音演示，而是能跨越配额限制、真实电话行为和真实并发场景仍保持连续性的体验。令人沮丧的是，产品构想其实已经很明确了，但基础设施看起来仍然成本高昂，而且很容易劣化。
值得为此构建吗？ 是的，但要有选择地做。需求信号是真实存在的，但产品必须解决可用性和连续性，而不只是把语音输进去、再把语音播出来。
3. 人们希望看到什么¶
一个能自动决定投入程度、路由和停止条件的控制平面¶
这是一个迫在眉睫的现实需求。@choopyplug1 解释 提到（18 个赞，9 条回复，393 次浏览，11 次收藏），人们现在想要的是一个能说出 none 的控制器，而不只是挑选工具。@0xRicker 展示了 展示了（40 个赞，12 条回复，2,729 次浏览，37 次收藏），一旦把小决策下放到更便宜的层级，人类需要投入的注意力会减少多少；而 @Da7_Tech 展示了（162 个赞，53 条回复，15,637 次浏览，67 次收藏）则表明，用户仍然不信任现有产品能在不打断他们的情况下，把日常步骤一路执行下去。
人们似乎想要的是这样一种运行时：它能根据眼前任务所需的自主程度，完成访谈、起草、验证、继续、暂停和收尾，而不是逼着用户每次会话都手动调整这些边界。
机会：直接。
可移植、经过审阅的记忆，能跨越工具切换和全新会话继续保留¶
这是一个有反复证据支持的现实需求。@prayag_dalal 报道 提到 Agent Beacon，因为跨执行框架团队希望记忆能够在 Claude Code、Cursor 和 Codex 之间迁移，而不至于沦为一堆未经审阅的笔记倾倒。@DivyanshT91162 整理汇编了 提到（6 个赞，3 条回复，419 次浏览），一个不断扩大的记忆产品生态，以及 @Da7_Tech 做出了（162 个赞、53 条回复、15,637 次浏览、67 次收藏）把面向用户的一面说得很明确：人们已经厌倦了在不同会话之间反复重申偏好、反复调试同一套设置。
需求并不只是更大的召回能力，而是经过审阅的召回：哪些经验教训仍然仍然适用、究竟哪个文件才真正控制行为，以及如何防止过时指令以“伪记忆”的形式再次冒出来。
机会：Direct.
面向代理工作的可携带身份、托管和证据保全¶
这是一个非常实际的需求，而且支持它的证据异常一致。@Subit_Crypto 认为（76 个赞、83 条回复、376 次浏览）主张采用链上身份、在报价被接受时启动托管，并在提交时记录交付物哈希。@Str_kerX 认为（105 个赞、26 条回复、8,242 次浏览）指出，证据必须在工作进行过程中就被保存下来，否则代理纠纷最终会败给最简单的自然损耗。@Hemtee5 补充说（33 个赞、16 条回复、483 次浏览）则表示，即便结算通道再完善，如果没有合格供给真正出现在真实工作里，也解决不了市场问题。
人们似乎并不想要一个更漂亮的代理目录。他们想要的是这样一层：能够证明是谁完成了工作、托管资金、保存证据、分流纠纷，并让成功经验能够跨市场迁移。
机会：Direct.
具备稳定外部身份的“电话级”代理¶
这个需求同时夹杂着实用和情感层面的诉求。@Musecases 认为（19 个赞、7 条回复、2,641 次浏览、14 次收藏）指出，重要的功能不只是“语音”，而是一个能够持续积累联系历史和信任的永久号码。@FredaDuan 展示了（23 个赞、1 条回复、1,549 次浏览、30 次收藏）则表明，这类产品的规模规划已经开始变成基础设施层面的讨论，而不只是演示效果的讨论。
人们似乎真正想要的是一个可触达、且具备连续性的代理：同一个号码、同一份上下文，以及足够的系统容量，不至于在高强度使用下陷入延迟或额度耗尽。
机会：Competitive.
4. 在用的工具与方法¶
| 工具 | 类别 | 情绪倾向 | 优势 | 局限 |
|---|---|---|---|---|
| OpenCode / Opencode 2.5 | 编码 harness | (+) | 普遍认为 harness 的质量会实质性改变结果；Jev 集成和浏览器工具扩展了运行时可处理的范围 | 内置能力相关的 UX 仍然不够均衡；产品表层变化很快 |
| Claude Code Dynamic Workflows | 编排/运行时功能 | (+) | 基于脚本的多代理编排、代码级分支、利于验证的流程，以及比“主代理提示词堆”更好的结构 | 最大价值似乎体现在更大的任务上；编排本身仍会增加复杂度和成本 |
| Droid | 代理平台 | (+/-) | 强缓存利用、宽松的多池配额、跨模型一致性、打磨良好的桌面 UX，以及广泛的任务覆盖 | 还没有真正的记忆层；语音会在额度受限时关闭；长时思考运行可能会被过早中止 |
| Jev / Jev MCP | 控制器 / 路由层 | (+) | 低成本的类型化决策、基于置信度的门控、有效的工具选择，以及显著更低的升级开销 | 阈值设计很关键；如果周边 harness 无法保持干净状态，仍然会失败 |
| JAZ | 研究框架 | (+/-) | 极简的递归 invoke 框架，以及在特定任务上颇具前景的效率声明 |
仍处于早期，且明显带有 benchmark 导向；需要更广泛的真实世界验证 |
llama.cpp |
本地推理运行时 | (+) | 暴露上下文窗口、GPU offload、KV-cache、speculative decoding，以及构建者真正需要理解的其他控制项 | 学习曲线高于封装型产品；对非技术用户来说不够开箱即用 |
| Learn Harness Engineering | 教育资源 | (+) | 为构建者提供了关于环境、状态、验证和控制的共享词汇；14 节课和 8 个项目构成了可复用的训练材料 | 这是课程，不是运行时；构建者仍需自行实现自己的技术栈 |
| Agent Beacon | 记忆层 | (+) | 跨 harness 的轨迹捕获、经审阅的经验教训、MCP/Agent Skills 检索，以及在 Claude Code/Cursor/Codex 之间保持连续性 | 需要审阅和整理；记忆质量取决于是否进行有纪律的捕获 |
| Nerve | 自托管代理运行时 | (+) | 持久记忆、基于审批的规划、cron jobs、多渠道收件箱，以及在同一运行时中的 personal/worker 模式 | 比托管式代理工具有更高的运维负担；需要自托管纪律 |
| Bolna | 语音代理编排平台 | (+) | 端到端 telephony/ASR/LLM/TTS 管线，支持服务商选择和本地 Docker 部署 | 相比单一托管 API 仍需更多底层拼装；运营复杂性依然存在 |
| Muse + Bland Agent Phone Plan | 面向消费者的语音/身份栈 | (+/-) | 持久号码、类似运营商的连续性，以及清晰的代理外部身份 | 存在区域限制、并发上限，以及规模化时真实的基础设施成本 |
| TermiX / AACP | 市场 + 结算协议 | (+/-) | 托管、交付哈希、挑战窗口、可携带声誉，以及面向代理的原生技能流 | 经过验证的供给仍然稀缺，纠纷/证据系统也还没有在大规模下经历实战检验 |
当产品把控制权或连续性明确展现出来时，满意度最高。人们喜欢那些能暴露服务层、把决策路由与昂贵推理分离、保留经审阅记忆，或留下清晰可见结算轨迹的系统。
主导性的变通模式，是把职责拆分到不同层：用前沿模型处理重度推理，用更便宜的控制器处理离散决策，用外部记忆系统维持连续性，再用协议层或技能层执行。这种架构很强大，但也恰恰说明了今天的一体化产品仍然欠缺什么。
迁移模式也很清楚。构建者正在从单窗口聊天转向 harness、运行时和控制平面；从“每次新会话就失忆”转向可审阅记忆；也从市场演示模型转向结算与证据基础设施。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Learn Harness Engineering | walkinglabs | 关于构建可靠编码代理 harness 的开源课程 | 为构建者提供可复用的状态、验证、环境设计和控制模式 | Markdown/docs 课程、repo 练习、前沿 harness 拆解 | 已发布 | 推文, 仓库 |
| RRSI | Google Research | 围绕冻结模型构建的代理 harness 递归自我改进框架 | 在不重新训练基础模型的情况下提升代理性能，并尝试避免对 benchmark 的过拟合 | Python、benchmark 适配器、harness 搜索， | 正则化规则 | 研究 |
| Nerve | ClickHouse | 面向个人助理和工作代理的自托管运行时 | 用于运行具备持久记忆、审批、调度和多渠道输入能力的长生命周期代理 | Claude Agent SDK、Python 后端、Web UI、Telegram、cron、记忆/搜索 | 测试版 | 推文, 仓库 |
| Bolna | bolna-ai | 面向语音代理的开源编排平台 | 无需从零开始手动打通电话、ASR、LLM 和 TTS 各层 | Python、WebSockets、提供商适配器、Docker 本地部署 | 测试版 | 推文, 仓库 |
| Agent Beacon | Asymptote Labs | 面向编程代理的跨 harness 项目记忆与已审阅经验沉淀 | 避免在 Claude Code、Cursor 和 Codex 之间反复进行设置提示和重复学习 | 本地 trace 捕获、MCP、Agent Skills、已审阅记忆工作流 | 测试版 | 推文, 仓库 |
| TermiX 上的 Holo Card Studio | TermiX 列表中的 HoloCardMaker | 由代理销售的微服务，可将用户照片转换为 3D 全息收藏卡 | 这表明，小而定义明确的代理任务，也可以清晰完成报价、托管、交付和结算 | TermiX 上架流程、托管、已验证卖家元数据、信誉/通过率统计 | 已发布 | 推文 |
学习 Harness 工程 是这份数据集中最明确的教育信号。它把原本主要散落在线程讨论和产品经验中的内容，整理成了可复用的方法：14 节课程、8 个项目，并明确覆盖状态、验证和控制。
RRSI 之所以突出，是因为它将 harness 视为一个持续演进的系统，而不是固定的提示词外壳。仓库和摘要都强调用正则化来避免过拟合，这使它更像一种严肃的工程方法，而不只是基准测试噱头。
Nerve、Bolna 和 Agent Beacon 都从不同角度指向同一种构建模式：长生命周期运行时、语音编排和记忆连续性，正逐渐成为彼此独立的产品层，而不再只是隐藏在单一聊天应用中的功能。Holo Card Studio on TermiX 之所以重要，是因为它把 agent-commerce 的叙事变成了一项真正可运行的低客单价服务。列表截图暴露了完整的买家流程：明确的交付成果、即时报价、可见的信誉/通过率元数据，以及结算路径，而不是空泛地兜售“未来工作形态”。
6. 新的和值得关注的¶
6.1 Claude Code 的动态工作流看起来像一次真正的编排升级¶
@daniel_mac8 报道称（201 个赞，26 条回复，14,834 次浏览，79 次收藏）表示，Claude Code 配合动态工作流和 Opus 5.5，带来了他迄今见过最好的多智能体编排体验；而他在回复中说，随着参与的智能体增多，系统也不会变得“混乱”。Anthropic 链接的 动态工作流指南 则明确说明了这次架构转变：Claude 会生成一个 JavaScript 编排脚本，通过工作流运行时执行，并利用代码结构完成分支与验证，而不是把所有内容都塞进单个主智能体的提示上下文中。
6.2 RRSI 让自我改进型 harness 变得具体，不再只是空谈¶
@beamnxw 强调了（29 个赞，10 条回复，396 次浏览，17 次收藏）RRSI，这是一个围绕冻结模型演化提示词、工具、记忆、控制流、上下文管理、技能和子智能体的框架。这之所以重要，是因为该仓库把自我改进表述为一个可衡量的搜索问题，并通过正则化防止过拟合，而不只是宣称“这个智能体会重写自己”。放在当天更广泛的 harness 讨论背景下看，RRSI 是最清晰的信号之一，说明自我改进型智能体系统正在走出口号阶段。
6.3 持久电话号码正把消费级智能体推向真实身份¶
@Musecases 认为（19 个赞，7 条回复，2,641 次浏览，14 次收藏）称，Bland 的新电话套餐给 Muse 提供了一个持久号码，这让语音智能体不再只是一个可拨通的演示，而更接近一项可被寻址的服务。链接文章补充了运营约束——覆盖美国/加拿大、一次仅支持一个并发通话、每小时最多 60 通、每天最多 500 通——而 @FredaDuan 估计（23 个赞，1 条回复，1,549 次浏览，30 次收藏）则指出，这种连续性在超大规模下可能消耗多少基础设施。合起来看，这两篇帖子把讨论从“AI 能打电话”推进到了“当人们真的开始依赖它时，身份和容量会是什么样”。
7. 机会在哪里¶
**+++］ 可审查的记忆与指令治理** — 来自 ［@Da7_Tech 的 Droid 评测的证据、@prayag_dalal 的 Agent Beacon 帖子 和 @DivyanshT91162 的记忆综述 都指向同一个缺口：用户想要连续性，但他们也想知道哪些经验仍然有效、harness 实际在读取哪些规则，以及某个被记住的修复应在何时失效。这是个强机会点，因为这种痛点已经广泛存在于各类编码智能体中，而不是某一款工具的孤立问题。
**+++］ 面向自主性预算的控制器基础设施** — 证据来自 ［@choopyplug1 的 Jev 工作流帖子、@0xRicker 的执行统计、@gippp69 的成本对比 和 @daniel_mac8 的工作流帖子 都指向同一个机会：一种能自行决定何时维持低成本、何时调用工具、何时升级处理，以及何时让长时间运行的工作流无需询问就继续推进的软件。这是个强机会点，因为它同时触及成本、信任和吞吐量。
**++］ 面向代理工作 的结算与证据轨道** — 证据来自 ［@Subit_Crypto 的 AACP 帖子,@RifdahSR_11 的结算帖子串、@Str_kerX 的证据腐坏帖子 和 @EClock24 的争议示例 表明，市场对身份验证、托管、交付证明、日志留存和申诉路径存在需求。这一信号属中等偏强，因为这套架构很有吸引力，但这一品类仍需要形成规模，并在真实世界的反复纠纷中经受检验，产品才能真正成熟。
**++］ 面向狭窄、高信任代理服务的履约网络** — 证据来自 ［@ny14co 的 Holo Card Studio 示例 和 @Hemtee5 对 verified-supply 的批评 表明，边界清晰的服务已经能够成交，而开放式工作仍难以找到既愿意提供服务、又具备资质的供给。这一信号属中等，因为需求已经显现，但最终胜出的模式可能取决于先将特定品类产品化，之后通用型市场才会准备就绪。
**+］ 达到手机级别的代理身份与可用性** — 证据来自 ［@Musecases 的 Bland/Muse 帖子、@FredaDuan 的规模估算 和 @Da7_Tech 对语音使用的抱怨 指向了一项机会：围绕连续性、电信级可用性、配额设计，以及实时对话中的记忆能力。这一方向仍处于新兴阶段，因为产品需求显而易见，但基础设施和经济性仍在制约这一品类。
8. 要点¶
- 编排框架设计显然已经超越了模型层面的“炫耀资本”。 最有分量的帖子讨论的是编排、控制、缓存、记忆和服务内部机制，而不是某一次单独的模型发布。（来源、来源、来源、来源）
- 控制器层变得更具体，也更可量化。 与 Jev 相关的讨论，已经不再停留于“廉价路由”式说法，而是转向误用工具循环的应对方案、零升级执行统计、明确的月度成本差额，以及“earned autonomy”之类的治理思路。（来源、来源、来源、来源）
- 记忆正在分化为独立的产品层。 Agent Beacon、memory-project 汇总，以及 Droid 用户的抱怨共同表明，“直接使用更大的上下文窗口”已经不再是一个令人满意的答案。(来源, 来源, 来源)
- 智能体商业一方面变得更可落地，另一方面也更受质疑。 结算流程、哈希、证据保全和法院层级的设计都更细了，但与此同时，批评也在加深：除了范围严格限定的工作之外，经过验证的供给仍然稀缺。(来源, 来源, 来源, 来源)
- 面向消费者的智能体身份正变得足够真实，足以引发基础设施层面的测算。 一个长期固定的电话号码听起来像是产品功能，但当天的讨论很快扩展到并发上限、区域限制，以及吉瓦级的规划假设。(来源, 来源)