Agent 不再是一个聊天框：路由、记忆与人的工作边界｜8月3日核心人物推文精选

窗口：北京时间 2026 年 8 月 3 日 00:05 至 8 月 4 日 00:05。

今天的关键信号，不是又出现了一个更强的模型，而是 agent 开始被放进工作的组织结构里：谁负责把任务送到正确的 agent，谁保存记忆和技能，谁检查结果，人在系统里还剩下什么位置。

Aaron Levie 认为，数学、网络安全和代码这类很难的工作，反而可能因为「可验证」而更早被自动化；Guillermo Rauch 描述的 Vercel 内部 agent，则已经在承担公司日常工作。两条推文放在一起看，竞争焦点正在从模型本身移到应用层如何组织、测试和接管工作。

Levie 把工作分成了两类。数学、网络安全和代码虽然门槛高，但结果可以用测试、形式规则或运行结果检查。这样的客观反馈，一方面能给训练提供更清晰的奖励信号，另一方面也能在模型运行时大规模检查它是否做对了。

法律条款是否会被客户接受、营销活动该押哪个方向、销售对象愿意听什么、企业预算该定在哪里，就没有这么快的答案。它们依赖变化中的内外部因素、操作者的风险偏好和输入上下文，结果可能要过很久才知道对错。Levie 的判断是：模型能力继续上升后，真正需要重做的会是应用层流程，以及对知识工作的长期测试能力。这是 Box CEO 的个人判断，不是一份跨行业评测。1

这个区分比「模型能不能推理」更接近产品落地。对代码，测试可以在几分钟内给出反馈；对销售、管理和策略，产品必须保存过程、上下文和后续结果，才有机会知道一次建议到底有没有用。否则，agent 只是把不可验证的判断生产得更快。

Thariq 也从数学领域给出了一个方向判断：他认为数学中已经能看到 Jevons 悖论——当理解和讨论变得更容易，数学活动总量反而会上升，真正懂数学、能思考数学的人会更有需求。这里的「Jevons 悖论」原本指资源效率提升后，资源总使用量可能增加；Thariq 的用法是类比，不是数学劳动力市场的统计结论。2

Rauch 说，Vercel 内部过去已经有很多 agent：不同团队和个人各自构建、部署，结果像每个 agent 都有一个独立域名，入口太多。Vercel 的做法是让一个名为 @𝚟 的 agent 同时充当总入口和路由器，下面挂着子 agent、skills，并负责把任务转给合适的执行者。3

这不是简单的聊天机器人换了名字。路由器的存在，意味着用户不必先知道「哪个 agent 负责什么」；系统可以把选择模型、调用技能和转交任务藏在后面。Rauch 把它比作 monolith 或 monorepo，同时保留通过网络代理到其他 agent 的出口。这个比喻解释了架构方向，但不等于 Vercel 已经公开了完整实现或效果数据。

在另一条推文里，Rauch 进一步称 @𝚟 已经参与 Vercel 的日常工作，覆盖财务、沟通、文档、营销、工程和业务分析；他还说它有每个用户的记忆、个性化工作流与日程，并举例说自己让它定期检查 skills.sh 的变化并提醒他。这些都是公司 CEO 对内部系统的描述，不能当作独立验证的生产率数据。4

Rauch 还强调，接入某家大模型公司的 Slack 集成，不等于企业拥有自己的 agent。只有当企业能控制源代码、运行时、数据和 token 时，agent 才可能成为组织的一部分。这个判断的实际含义很具体：模型供应商提供能力，企业仍需要拥有任务入口、权限、记忆和成本账本。

Peter Yang 转述 NousResearch 联合创始人 Karan 对 Hermes Agent 的解释：Hermes 会自己建立帮助完成工作的 skills；后台的 Hermes Curator 会定期清理 skills 和记忆，询问哪些内容是「slop」、哪些地方可以更高效。由于项目开源，用户还可以按自己的标准修改清理循环。这里的产品能力与机制来自 Peter 对访谈的整理，Karan 的观点也不等于独立评测。5

一天后，Peter 又把这次访谈压缩成六条实践建议，其中最值得留意的有三条：个人 agent 的「个人」主要来自对话记忆和已经建立的 skills，而不只是底层模型；可以让一个 agent 执行，再让一个没有上下文的新 agent 独立评估错误、薄弱假设和缺失证据；自我改进的 agent 也需要标记长期不用的 skills，并把它们移到可恢复的归档里。6

这套设计把「长期 agent」拆成了几个可检查的部件：记忆让它知道用户是谁，skills 让它知道怎么做，独立评估器负责怀疑，清理任务负责阻止过去的临时方案无限堆积。它仍然是 Hermes 的具体做法，不应被写成所有 agent 都已具备的通用能力，但它比「agent 会自我进化」更接近可以落地的工程清单。

Dan Shipper 把 AI 带来的心理变化称为「agency rupture」，也就是原本每一步都需要人完成的任务突然可以交给模型。初期，人只看到模型完成了什么；用得更久后，人会看到两端的人工搭建：如何准备输入、约束任务、检查质量，再把结果接回真实工作；再往后，新的工作习惯稳定下来，模型的贡献反而变得不显眼，人重新说「这是我做的」。这是 Shipper 的经验性解释，不是心理学研究结论。7

这条观察和前面的 agent 架构正好接上：如果系统替人保存记忆、选择工具、执行任务，人的工作就会向定义目标、提供上下文、设计验收和承担后果移动。Shipper 的另一条短帖说，技术改变人的能力范围，也会改变人对「应该做什么」的直觉；它是哲学式判断，不能代替对具体职业的调查。8

swyx 分享了自己开发 Forge 时遇到的一个实际摩擦：平台和产品互相阻塞时，他可以在 Codex 中给线程排队，让项目在平台功能解除阻塞后继续推进；但他认为，更理想的 multi-agent harness 应该自动在平台与产品之间协调。这里是个人开发体验，不是 Codex 的完整功能说明，却点出了一个常见缺口：agent 能完成单个任务，不代表它能管理跨项目的依赖关系。9

他还记录了一个低互动但很具体的 computer-use 片段：Codex 代替他处理支持聊天，并把对方的回复和证据整理出来，以便升级处理。这个例子仍是一次现场记录，不能推出「computer use 已经可靠处理客服」；它的价值在于把 agent 的接管点放到了一个人原本需要逐句参与的沟通环节。10

过去一天的推文没有给出统一答案，但它们把同一件事拆成了可以逐项检查的部件：Levie 讨论应用层的长期测试，Rauch 讨论总路由与组织控制，Hermes 讨论记忆和清理，Shipper 讨论人的 agency，swyx 则展示跨项目协调还没有被完全解决。agent 的下一场竞争，已经不只是谁回答得更好，而是谁能把这些部件连成一条人愿意承担责任的工作链路。