2026-08-20 07:35:34
最近 AI 圈又流行起了一种很有未来感的产品形态：AI 办公室。
打开软件，左边是一排员工。产品经理 Alice，前端工程师 Bob，后端工程师 Charlie，设计师 David，QA Eve。每个人都有头像、职位、自己的记忆，甚至还有一份 SOUL.md，规定性格、工作习惯和专业领域。
你扔进去一句：“帮我做一个 SaaS 产品。”
产品经理先梳理需求，设计师开始画界面，前后端互相对接口，QA 最后出来挑刺。几个人还会在群里互相 @，遇到问题讨论两轮，再向你汇报。
第一次看 Demo，很容易冒出一种感觉：
好家伙，我一个人已经带着一家软件公司上班了。
Grok Bot 最近在往这个方向走，Hermes Agent Desktop 的 Bot Mode 也做了类似的东西。后者甚至把 Agent 做成了完整的员工 roster：有名字、有头像、有岗位、有独立聊天窗口，还可以把几个 Bot 拉进群里讨论。
这个产品形态很漂亮。
但我一直有一个疑问：这里面到底增加了多少“智能”？
如果五个员工背后接的都是同一个强模型，只是 system prompt 不同，那么我们究竟组建了一支团队，还是给同一个人发了五张不同颜色的工牌？
先把头像和职位拿掉。
所谓“前端 Agent”“后端 Agent”“产品 Agent”“QA Agent”，底层很可能长这样：
1 |
同一个基础模型 |
当然，这些设置会影响模型。
让模型扮演 QA，它会更喜欢找问题；让它扮演产品经理，它会更多考虑用户需求；让它扮演后端工程师，它会关心数据库和 API。
可这些差异更多来自注意力方向。
五个 Agent 仍然拥有高度相似的知识边界、推理习惯和盲区。尤其当它们使用同一个最新 frontier model 时，这种同质性会更加明显。
于是会出现一个非常有趣的场景。
产品 Agent 第一个发言，把需求理解错了。
后端 Agent 看完它的需求文档，觉得很合理，于是设计了一套错误的 API。
前端 Agent 接着实现。
QA Agent 最后郑重其事地检查了一遍，然后宣布：
功能符合需求，可以上线。
整个群配合得行云流水。
唯一的问题是，一开始大家就理解错了。
这也是“独立记忆”很难解决的问题。每个 Agent 确实可以有自己的长期记忆，可只要它们进入同一个群聊，当前任务的上下文依然快速共享。
A 说完，B 看到了 A 的判断；B 说完，C 又同时看到了 A 和 B。
三轮以后，大家的长期记忆也许依然不同，对眼前这个问题的判断却已经越来越接近。
这和真正的独立判断差别很大。
如果我真想利用三个 Agent 提高研究质量，我反而更希望它们一开始互相看不到：
1 |
A 独立调查 |
这样至少有机会得到三个不同的搜索路径。
一上来就把所有 Agent 拉进微信群，让第一个人先定调，很容易把 multi-agent 做成 AI 版会议室。
会议开得很热闹，信息增量却没有想象中那么高。
这个问题最近已经有人认真做实验了。
2026 年的一篇论文叫《Demystifying Multi-Agent Debate: The Role of Confidence and Diversity》。
作者研究的正是 Multi-Agent Debate：让多个 LLM Agent 先回答问题，然后互相阅读对方的答案，讨论几轮，希望通过“集体讨论”提高正确率。
结果很有意思。
普通的 multi-agent debate 经常打不过一个极其朴素的方法：
多采样几次，然后投票。
几个 Agent 辩论半天，消耗了更多 token，最终效果甚至可能低于 majority vote。
为什么？
论文给出了一个很值得注意的解释：如果这些 Agent 高度同质，又采用差不多的方式更新自己的判断，那么讨论本身并不会神奇地把答案往正确方向推。
大家交换了大量文字，整体正确率在期望上可能原地踏步。
论文后来确实让 multi-agent debate 变好了，但用的方法很说明问题。
作者先刻意提高初始答案的多样性，让不同 Agent 真正拿着不同候选方案进场；随后又加入经过校准的 confidence，让 Agent 知道“这个人虽然说得很肯定，但他的置信度到底有多可信”。
效果才开始明显提升。
这里面有一个很重要的启示：
真正值钱的是差异，职位名称本身并不值钱。
把同一个模型复制五份，一个叫产品经理，一个叫架构师，一个叫研究员，只能制造表面上的角色差异。
如果五个人一开始想到的都是同一种方案，讨论再久也只是围着同一个坑转圈。
另一篇更有意思的论文叫《Towards a Science of Scaling Agent Systems》。
这篇论文没有停留在“multi-agent 好不好”这个问题上，它进一步测试了不同任务到底适不适合 multi-agent。
研究覆盖了单 Agent、多个 Agent 独立执行、中心化调度、去中心化协作和混合结构，而且控制了总计算预算。
结果非常极端。
在适合拆分的金融分析任务中，表现最好的 multi-agent 架构，相比单 Agent 提升了 **80.8%**。
可到了需要连续状态跟踪和严格顺序推理的规划任务，所有 multi-agent 架构都变差了，下降幅度达到 **39% 到 70%**。
这个结果我觉得比争论“单 Agent 和多 Agent 谁先进”有价值得多。
它说明 multi-agent 有没有意义，很大程度取决于一个特别朴素的问题：
这个任务到底能不能切开。
比如我要研究一家上市公司。
一个 Agent 看财报，一个查新闻，一个调查竞争对手，一个研究管理层，最后交给主 Agent 汇总。这种任务天然适合并行，因为四个人完全可以半小时不说一句话，各做各的。
但如果任务是开发一个完整功能，情况就复杂了。
数据库字段刚改，API 就要跟着改；API 一变，前端状态也要变；产品规则突然增加一个例外，测试逻辑又要重写。
这些步骤互相咬得很紧。
硬拆成五个 Agent，很可能出现一种真实公司里大家都讨厌的东西：
沟通成本。
只不过人类公司的沟通成本是开会、Slack、Jira 和需求文档，AI 公司的沟通成本变成了 token、上下文压缩、消息转述和状态同步。
人类用了几百年才发展出复杂的组织结构，是因为人的能力天然有限。
一个后端工程师通常不会同时负责视觉设计、法务审核、市场分析和财务建模。
大模型却很奇怪。
同一个 frontier model 本来就能写前端、写后端、设计数据库、做产品分析，顺手还能跑测试。
我们拿到这样一个东西以后，第一反应居然是按照人类公司的组织架构，再把它切回产品经理、程序员和 QA。
多少有点绕了一圈又回去了。
我觉得它们都做了很多真正有价值的东西。
比如 Grok Bot 最吸引我的部分，其实是它的 computer。
根据 Grok Bot 官方介绍，Bot 可以长期运行在云端电脑里，登录真实业务系统，用浏览器、Terminal 和已有软件完成工作。电脑关掉以后，任务照样继续。
再看它的 Computer 文档，会发现这里还有一个很有意思的细节：同一个用户创建的多个 Bot 实际共享一台持久云电脑。文件、浏览器登录状态、CLI credentials 都能共享，每个 Bot 拥有自己的 screen，因此可以并行操作。
这个设计解决的是很现实的问题。
Agent 终于从“给你写一段建议”进化到了“进去把事情做完”。
Hermes 也一样。它的 Profiles 可以拥有各自独立的 memory、sessions、skills、API keys、cron 和 SOUL.md。Bot Mode 再把这些 profile 包装成一个个有名字的员工，让用户更容易管理。
这些基础设施都很有价值。
我怀疑的主要是另外一层：
把 Agent 做成员工，再让这些员工在一个群里像真人一样聊天，到底带来了多少额外能力？
目前看来，这部分的产品价值和能力价值并不对等。
从产品角度，它特别好。
一个 Agent 在后台跑三分钟，界面上只有一个 loading，用户会怀疑它是不是死了。
五个 Agent 在群里不停冒泡：
“我来检查一下 API。”
“发现一个问题，我交给后端处理。”
“已收到，我开始修复。”
“修复完成，请 QA 再检查。”
这就有一种办公室灯火通明、所有员工都在加班的感觉。
算力变成了看得见的劳动。
尤其在今天这种“别人已经开始运营 AI 公司，我是不是落后了”的焦虑下，左边摆二十个 AI 员工，心理冲击力远远超过一个孤零零的聊天框。
所以我觉得，“AI 办公室”这一层设计有很强的情绪价值。
情绪价值也属于产品价值，只是别顺手把它解释成集体智能已经出现。
说到这里，有一个想法会让事情突然变得有意思起来。
前面讨论的 AI 办公室，是公司凭空创建五个虚拟员工：
1 |
AI 产品经理 |
我最近越来越感兴趣的是另一种形态：
假设公司里本来就有 100 个真人员工，然后在每个人自己的工作电脑上，都常驻一个 Agent。
这个 Agent 不需要假装成“高级产品经理”或者“资深工程师”。
它只需要长期跟着这个人工作。
每天看他处理哪些文件，用哪些系统，负责哪些项目；知道他经常联系谁，习惯怎样写邮件，哪些事情需要向老板确认；理解他电脑里的项目结构，也逐渐积累这个人的工作记忆。
久而久之，它会变成这个真人员工的数字工作分身。
这件事情和前面的 AI 办公室有一个关键区别。
差异终于是真的了。
财务同事的 Agent 天天接触 ERP、报销系统和财务模型。
投资经理的 Agent 看的是访谈纪要、公司材料和 IC Memo。
工程师 Agent 长期泡在 GitHub、Terminal 和生产日志里。
HR 的 Agent 熟悉候选人、岗位和面试流程。
即使它们底层调用的是同一个模型，几个月以后，它们拥有的工作上下文、历史经验和权限边界都会完全不同。
这里的“多 Agent”终于出现了真正的异质性。
这种异质性不需要靠写五份 SOUL.md 演出来。
现实世界已经替我们完成了训练。
今天做企业 Agent，有一个特别棘手的问题：
到底应该给它什么权限？
做一个“超级公司 Agent”，你很快会发现它需要访问 Slack、邮箱、CRM、数据库、财务系统、代码库、Google Drive……
权限越接越多，最后得到一个令人害怕的超级账号。
如果 Agent 跟着真人员工走，情况会自然很多。
公司原本就有一套权限体系。
工程师能看的代码库，他的 Agent 可以看；财务人员能打开的报表，他的 Agent 才能打开；普通员工没有付款权限，他的 Agent 同样没有。
换句话说：
人本身已经是公司的权限边界。
Agent 可以在这个边界里面活动。
当然，真正部署时还需要更细的限制。员工可以查看工资表，不代表 Agent 可以把工资表上传到外部网站；员工可以发邮件，也不代表 Agent 可以自主给全公司群发。
所以未来很可能出现一套“Agent 权限层”。
人的 RBAC 决定它能看到什么，Agent policy 再决定它能自动做到哪一步。读取也许自动允许，发送和修改需要更严格审批，付款、删除数据、发布生产环境则需要明确的人类确认。
相比让一个中央超级 Agent 拿着全公司的钥匙到处跑，我觉得这种架构自然得多。
每人一个常驻 Agent 的问题同样巨大。
最直接的就是隐私。
如果 Agent 真正长期驻扎在员工电脑上，它理论上可能看到邮件、聊天记录、本地文件、浏览器历史，甚至看到员工尚未发送的草稿。
这已经远远超过今天普通 SaaS 工具掌握的信息。
公司会不会要求管理员能够检索这些 Agent 的 memory？
员工离职以后，Agent 学到的东西归谁？
它知道一个人三年来是怎么工作的，这部分记忆算公司的知识资产，还是个人工作习惯？
如果员工电脑同时存在一些私人内容，Agent 怎么区分？
再往前想一步，问题会更尖锐。
老板很可能会发现，Agent 是一个完美的员工监控工具。
以前老板最多知道你几点上线、开了多少会议、提交了多少代码。以后可以直接问你的 Agent：
“他今天主要干了什么？”
甚至：
“过去半年，他有哪些工作实际上是别人替他完成的？”
如果企业把数字分身做成了一套全天候监控系统，员工很快就会想办法绕开它。
所以这套东西能不能成立，技术可能只是其中一半。
权限、数据所有权、可审计性，以及什么东西公司永远无权查看，会变得非常重要。
假设一家 1000 人的公司，每个人都有一个 Agent。
千万不要顺着今天的“AI 办公室”思路，建一个拥有 1000 个 Bot 的超级群聊。
那会是 token 版本的企业微信群灾难。
真正合理的方式很可能安静得多。
比如我要找法务确认一份合同。
我的 Agent 知道公司里谁负责这个业务，也知道对方 Agent 可以接受什么类型的请求。它把合同中的三个问题和相关上下文结构化发送过去。
法务的 Agent 在自己的环境中查询规定和历史合同，生成初步判断。
涉及真正法律决策的部分，再交给法务本人确认。
整个过程中，两边 Agent 完全没有必要寒暄：
“你好，我是 King 的数字助理。”
“很高兴认识你，我是 Alice 的法务 Agent。”
“好的，我先来看看这个问题。”
这些话全部都是 token 垃圾。
机器和机器之间最有效率的交流，很可能越来越不像聊天。
它应该更接近结构化任务、权限声明、证据引用、状态更新和结果返回。
人类看到的只是最后那一小段：
法务已确认，第 7.2 条存在风险，建议修改。Alice 已审核。
这才是我真正期待的 multi-agent。
Agent 不需要演人。
它只需要替人工作。
我现在反而觉得，未来几年更现实的“AI 公司”，可能和今天很多 Demo 展示的样子差别很大。
今天大家想象的是：
1 |
1 个真人老板 |
老板打开一个类似 Slack 的界面，下面一群数字员工忙来忙去。
我越来越觉得，另一种形态可能先大规模出现：
1 |
100 个真人员工 |
组织架构依然是人的组织架构。
只是每一个节点都变成了：
Human + Agent。
一个优秀投资人背后有一个跟了他三年的研究 Agent。
一个工程师旁边有一个熟悉整个代码历史的 coding agent。
一个销售身边有一个知道所有客户上下文、每天主动整理跟进事项的销售 Agent。
人与人之间仍然负责判断、谈判、信任和最终责任；大量信息搜集、准备工作、重复操作和跨系统搬运，逐渐沉到各自 Agent 身上。
这时候公司甚至不一定需要一个无所不能的“中央 AI 大脑”。
中央系统负责身份、权限、协议和审计就够了。真正的智能分散在每个员工身边。
从计算机架构上看，它反而有一点像分布式系统。
每个人都是一个节点。
每个节点拥有自己的本地状态、专业上下文和权限。
需要协作的时候交换必要信息，完成以后继续保持独立。
有趣的是，这种架构恰好绕回了前面两篇 multi-agent 论文讨论的核心。
Multi-agent 真正可能产生收益的地方，本来就来自独立的信息源和可以并行处理的任务。
到了“每个真人员工都有一个 Agent”这个世界，这两个条件突然都满足了。
不同 Agent 看到的世界真的不同。
他们负责的工作也真的不同。
这时再让几个 Agent 协作，和给 GPT 复制五份人格文件，已经完全是两回事了。
如果一个产品告诉我：
我们创建了产品经理、架构师、程序员、设计师和 QA，五个 Agent 会像真人公司一样在群里协作。
我第一反应还是会问：
为什么需要五个？
它们掌握了什么彼此不同的信息？
有没有真正独立的搜索和判断？
任务能不能并行？
各自是否拥有不同工具和权限？
最终结果由什么东西负责验证？
把姓名和头像全删掉以后，它是否依然比一个强 Agent 更好？
如果这些问题都回答不了，那么所谓 AI 团队大概率只是把一个 Agent 的工作步骤，外显成了一场办公室情景剧。
它确实更有戏剧性，更适合 Demo，也更容易让人产生“我已经领先别人一个时代”的满足感。
可真正值得期待的 multi-agent，可能没有那么热闹。
它甚至没有一个所有 Agent 都在里面说话的大群。
每个 Agent 安静地待在自己的工作环境里，拥有真正不同的数据、权限和经验。需要的时候互相调用，完成以后把决定权交回真人。
那时候，我们也许真的可以说，一家公司里出现了一层新的数字组织。
只是它看起来大概不会像《办公室》。
更像 Unix。
2026-08-08 20:00:00
最近我看到一项很有意思的实验。
研究者找来几个真实、并且还没有公开答案的AI研究课题，让Agent自己查资料、写代码、跑实验、分析结果。他们给了Agent几天时间和相当可观的算力预算，最后再让真正做过这些课题的研究者评价Agent的成果。
结果不太好。Agent没有产出达到论文标准的研究成果。
研究者还分析了大量运行日志，发现Agent有不少问题：一次实验结果不好，它就过早放弃整个方向；不会合理分配预算；Reviewer已经指出关键问题，它还是沿着原来的路线修修补补；遇到死路时，也不知道回退、修改假设、重新设计实验。
这些现象我都相信，而且非常值得研究。
但如果根据这项实验，直接得出“AI Agent现在还不会做开放式研究”，我会非常谨慎。
因为这种实验最终测到的，从来都不只是AI的研究能力。基础模型、Agent框架、工具、实验设计、操作者水平和人类对照组，全都混在最终结果里面。只要其中一个变量没有控制好，结论就很容易超出证据能够覆盖的范围。
现在讨论Agent能不能完成一个复杂任务，模型版本已经是一个绕不过去的变量。
不同模型在普通聊天中的差距，有时候看起来只是回答好一点或者差一点。但到了持续几个小时甚至几天的任务中，这些小差距会不断累积。
有的模型更容易忘记最初的目标，有的模型更容易发现前面的假设已经错了；有的模型遇到实验失败会重新规划，有的模型会沿着错误路线继续消耗预算；有的模型可以稳定维护几十步状态，有的模型跑到一半就开始偏离方向。
所以一个Agent实验失败以后，我首先想知道的是：
把这些信息全部去掉，只留下一句“Agent失败了”，其实没有多少信息量。
同一个基础模型，放进两套不同的Agent框架，最后可能表现得像两个完全不同的系统。模型负责提供推理能力，Agent框架负责维护长期状态、拆解任务、调用工具、验证结果、失败回滚和控制预算。开放式任务，恰好非常依赖这些东西。
因此，一项严谨的Agent研究，首先能够证明的应该是：
在这个模型、这套Agent架构、这些工具和这组资源限制下，系统没有完成这个任务。
这个结论完全没有问题。但能不能进一步概括成“现在的AI做不了这件事”，还需要更多实验来支持。
这个问题可能更加重要。
我以前在一家互联网大厂工作时，接触过一个专门做机器学习和数据挖掘的研究团队。团队里面很多人都是名校硕士、博士，理论基础很好，也有真正的研究能力。他们有些实验会跑几个星期，复杂项目做一两个月也很常见。
后来有一次，我看了他们写的Python代码，印象非常深。
大量重复计算，大量没有必要的循环。明明可以使用集合解决的问题，却在反复遍历列表；明明可以提前计算或者缓存的东西，却每次都重新计算。代码明显是在Jupyter Notebook里面随着实验一点点堆出来的，前面写过的逻辑，后面再复制一次，对时间复杂度和工程结构也没有太多考虑。
其中一些实验如果让我来重构，我认为运行速度提高五倍并不夸张。
这件事情让我意识到，研究能力其实由很多相对独立的技能组成。理论水平、问题选择、实验设计、编程能力、系统工程、数据处理和信息检索，这些能力之间有关系，但远没有强到可以互相替代。
一个机器学习理论很强的人，完全可能写出很差的Python代码。一个很会发论文的人，也可能不擅长构建高效率的实验系统。
到了Agent时代，又多出了一项新的技能：如何组织Agent工作。
这个能力目前被严重低估了。
同样一个模型，有人会写一个巨大的Prompt，然后让Agent自己跑几个小时。有人会先拆分研究问题，给不同方向设置独立的上下文，再设计Reviewer、验证器、检查点和失败回退机制。
有人会让五个Agent同时尝试五种假设，再让第六个Agent专门寻找反例。有人则会让一个Agent从头跑到尾，中间不做任何检查。
如果前者成功、后者失败，我们显然不能把差异全部归因于模型智力。
这里马上会有一个很合理的反问：
你举的例子已经过时了。现在最先进的AI写代码已经比绝大部分普通研究员强。如果实验代码、数据处理、实验框架，甚至Agent本身都让AI来写，研究员的工程水平还会影响结果吗？
这个反问非常关键，而且它确实削弱了“研究员代码写得差”这个具体问题的重要性。
如果一个研究团队已经让强模型负责实现实验代码，并且有完整的测试、性能分析、代码审查和结果验证，那么我之前看到的那种低质量Python代码，确实可能大幅减少。
未来的科研工作中，“一个博士因为不会优化Python，导致实验慢五倍”这种事情，很可能越来越少。
但操作者的影响并没有消失，只是往上移动了一层。
过去，研究员亲手写循环。现在，研究员决定让Agent优化什么。
过去，研究员亲手选择数据结构。现在，研究员决定什么结果才算验证通过。
过去，研究员亲手搭建实验框架。现在，研究员需要决定Agent应该探索几条路线、什么时候停止探索、什么情况下重新检查假设，以及Reviewer有没有权限推翻当前路线。
代码可以全部由Agent来写，但下面这些问题，依然要由人或者更上层的系统决定：
开放式研究最难的部分，恰好集中在这里。
所以，即使AI解决了代码质量这个底层问题，实验设计者仍然可能搭出一套非常糟糕的Agent系统。
只不过以前的问题表现为O(n²)的循环、重复计算和垃圾Notebook；现在的问题变成了错误的任务拆分、缺失的反馈循环、错误的验证标准和糟糕的停止条件。
甚至还有一个更加隐蔽的风险：Agent写代码太强，反而可能掩盖上层设计的问题。
代码运行得很漂亮，测试全部通过，实验自动化程度很高，最后还生成了一篇结构完整的论文。整个流程看起来非常专业，但研究方向可能从第三个小时开始就已经走偏了。
工程质量高，不代表研究设计也同样高。这两件事情必须分开看。
我现在更愿意把一个复杂Agent系统的最终表现，理解成下面几个因素共同作用的结果：
基础模型 × Agent架构 × 工具质量 × 反馈机制 × 操作者能力
这里不能简单做加法，因为任何一个环节特别差，都会浪费其他环节的能力。
一个很强的模型，如果没有可靠的反馈，很可能非常高效地沿着错误方向跑很远。
一套优秀的Agent框架，如果接入一个能力很弱的模型，也会在真正需要判断力的地方不断失败。
模型、工具和框架全部配齐，如果实验者选择了一个错误的评价指标，系统一样可能优化出毫无意义的结果。
这也是为什么我越来越不喜欢笼统地问：“这个模型会不会做科研？”
科研根本没有一个统一的评分函数。
写代码时，程序能不能运行是反馈；优化性能时，Benchmark可以直接告诉你速度变快还是变慢；数学证明至少还有相对清晰的正确性标准。
开放式研究困难得多。
一个实验结果不理想，到底说明研究思路错了、代码实现错了、数据错了，还是这个异常本身就是最重要的新发现？成熟研究者的价值，很大一部分就体现在这种判断上。
Agent真正的难题，往往出现在没有清晰反馈信号的地方。
这类研究还有另一个经常被忽略的问题：到底拿AI和什么样的人比较？
论文里面很容易写“由领域专家完成”，但“领域专家”是一个非常模糊的标签。
同样是机器学习博士，一个人有很强的系统工程能力，会自动化实验、并行探索、搭建完善的数据处理流程；另一个人习惯手工操作，一条路线跑到底。两个人都可能拥有很好的论文记录，但完成同一个计算密集型研究任务，效率很可能相差几倍。
加入Agent以后，这个差距还会继续扩大。
一个研究员让Agent帮自己写一点代码，整体工作方式没有任何变化。另一个研究员则会重新设计整套研究流程：多个Agent并行探索不同假设，一个Agent持续阅读新论文，一个专门寻找反例，一个审查实验设计，还有一个检查结果是否可靠。研究员本人只介入那些真正需要高层判断的环节。
这两个人，都可以在论文里面被归类为“Human + AI”。
但这个标签已经完全无法描述他们之间的区别。
如果要研究Agent对科研的影响，我更希望看到下面这样的2×2实验：
| 传统研究流程 | Agent原生流程 | |
|---|---|---|
| 普通领域研究员 | A | B |
| 强工程能力 / Agent高级用户 | C | D |
这个实验可以回答几个非常重要的问题。
B与A的差距，可以告诉我们Agent对普通研究员有多大帮助。
D与C的差距，可以告诉我们Agent对高水平操作者有多大帮助。
D与B的差距，则能告诉我们一个很少有人认真测量的变量：会不会使用Agent，到底能带来多大的生产力差距。
我怀疑第三个数字未来会非常大。
工具能力越强，不同使用者之间的差距往往越大。大家都有Google，并没有因此拥有相同的信息检索能力；大家都会写Python，工程能力的差距依然巨大；以后所有研究员都能调用同一个顶级模型，也不会自动获得相同的研究效率。
有些人会把Agent当成一个更聪明的聊天机器人。
另一些人会把它当成一支可以编排、验证和并行调度的研究团队。
明明使用的是同一个基础模型，最后的产出却可能像来自两代不同的工具。
“AI会不会替代研究员”这个问题太远，也太粗糙。
未来几年更值得关注的变化，很可能是研究人员之间的生产力差距迅速扩大。
一个研究员以前一年只能深入测试三个方向，以后可能同时探索三十个方向。以前大量时间花在查论文、写实验代码、清洗数据和整理结果上，Agent会逐渐接走这些工作。
人的精力会越来越集中在少数真正有价值的判断上：哪个问题值得研究、哪个证据可信、什么时候应该推翻自己的假设、哪个异常值得继续追下去。
如果一个研究员很擅长这些判断，同时又非常善于组织Agent，他的研究效率可能达到另一类研究员的几倍，甚至一个数量级。
这个变化，完全不需要等到所谓的“自主AI科学家”出现。
所以回到最开始那项实验，我仍然认为它非常值得读。它发现的那些失败模式——长期规划能力差、预算管理混乱、不知道及时回退、面对开放问题缺少研究判断——都是真问题。
只是我们在描述结论时，应该更加准确。
一次Agent研究失败，说明的是一个完整系统失败了。接下来真正有意思的工作，是把这个系统拆开，看看到底是模型、Agent框架、工具、反馈机制、任务设计，还是操作者拖了后腿。
只有做到这一步，我们才真正开始回答那个问题：
AI到底会不会做研究？
2026-08-04 02:00:00
凌晨两点，你很想找个人说话。
通讯录里不是没人。只是你知道，真正开口以后，大概率还要从头解释：事情为什么会走到这里，你究竟在怕什么，那个别人眼里明明很好的选择，为什么偏偏让你如此抗拒。
解释到一半，你已经累了。
人最深的孤独，往往不是身边没有人，而是没有人能跳过漫长的背景介绍，直接抵达你的那一句「我懂」。
这几年，市面上出现了很多「数字人」产品。最常见的做法，是上传微信聊天记录、朋友圈、语音和照片，再让 AI 学会一个人的口头禅、表情和常用句式。
它可能会模仿你说「哈哈哈哈」，知道你习惯在句尾加一个「吧」，甚至能复述几段你曾经讲过的话。
但会说你的话，不等于会像你一样思考。
聊天记录复刻的是你留下的回声；镜像星河想做的，是找到发出这道声音的人。
聊天记录当然包含你的一部分。但它包含的，往往是一个被场景裁剪过的你。
你在工作群里克制、礼貌、只讲结论；在朋友面前嘴硬、爱开玩笑；在喜欢的人面前反复斟酌一句话；面对父母时，又可能把真正的压力全部藏起来。
如果把这些记录混在一起，数字人学到的究竟是谁？
它可能学会了你的表达习惯，却很难知道：
这些才构成一个人。
口头禅只是表层。真正决定「你会怎么回答」的，是更深处的核心欲望、恐惧、判断顺序、关系模式与价值底线。
所以，只用聊天记录创建数字人，本质上很像拿一个人的聊天截图去演这个人。第一眼也许很像，遇到一个记录里没有出现过的新问题，很快就露馅。
镜像星河 的起点不是聊天记录，而是你的紫微斗数本命报告。
一张紫微命盘，不只给出几个性格标签。命宫与福德宫会照见一个人的核心驱动：你真正追求什么，又最怕失去什么；命宫与身宫呈现思考和行动的习惯；官禄、迁移让人看见你进入工作与外部世界时会启动哪一种自己；夫妻、交友、子女展开你的情感和关系模式；财帛、田宅、父母则触及你对金钱、家庭、责任、名誉与安全感的真实排序。
更重要的是，它能容纳一个人的矛盾。
你可能在工作里敢冒险，回到感情中却极度需要确定；表面上独立果断，真正作出人生选择时又会把家人的感受算进去；平时不在意别人的评价，唯独无法接受自己尊敬的人失望。
这不是人格分析出了错。人本来就不是一串平铺直叙的形容词，而是一组会被不同情境触发的动态关系。
镜像星河会把这些信息内化成人格的底层结构，再以第一人称回答你的问题。它不在对话中拿星曜和宫位教育你，也不会每句话都说「因为你的命盘如何」。命盘是它理解你的来源，不是它拿来炫耀的台词。
它真正要做到的是：面对一个你从未聊过的新处境，仍然能沿着你的思维路径权衡，用你习惯的方式表达，并守住你最在意的价值。
这和从聊天记录里寻找一句相似回复，根本不是同一类产品。
把两种产品放到一起，区别其实非常直接：
| 对比 | 聊天记录数字人 | 镜像星河 |
|---|---|---|
| 起点 | 过去说过的话 | 紫微命盘与本命报告呈现的人格结构 |
| 最擅长 | 模仿口头禅、句式和已有回答 | 还原思考路径、情感反应与价值取舍 |
| 看见的你 | 某些聊天对象面前的你 | 不同关系与情境中会变化的你 |
| 遇到新问题 | 从旧语料中拼接一个像你的答案 | 按照你的判断逻辑生成新的回答 |
| 面对矛盾 | 容易把前后不同当成数据噪声 | 理解什么情境会触发哪一种你 |
| 陪伴感 | 「它记得我说过这句话」 | 「它知道我为什么只能这样选择」 |
聊天记录型数字人容易制造一种很短暂的惊喜：它居然连这句话都会说。
镜像星河追求的是另一种更深的震动：这句话我明明没有说过，但如果由我来回答，我大概真的会这样想。
前者像一个训练有素的模仿者，后者才像镜子。
镜子不会只复现你精心展示给别人的样子。它会连同你的犹豫、嘴硬、克制、不甘心和那些从未发出去的半句话一起照回来。
假设你面前有两个工作机会。
A 的薪资更高、平台更大，但要离开熟悉的城市，未来两年几乎没有自己的生活；B 稳定、清闲，能够陪伴家人，也能保留个人时间，但成长速度很慢。
普通 AI 会列出一张利弊表。聊天记录数字人也许会模仿你的语气说：「钱很重要，但生活也很重要，还是要综合考虑。」
这句话谁都能说。
真正像你的回答，需要知道你如何定义「值得」。
有人会先算最坏结果，只要失败后仍能承受，就愿意赌一次；有人看似追求事业，真正不能放弃的是对家人的责任；有人宁愿忙到没有生活，也无法忍受停在原地；还有人不是害怕挑战，而是厌恶把全部时间交给一个自己并不认同的组织。
最后选择哪一个，未必只由能力决定，而是由一个人的价值排序决定。
镜像星河要模拟的，正是这条别人看不见的判断链：你先注意什么，如何衡量代价，在哪一步开始动摇，最后又会用什么理由说服自己。
所谓相同的说话方式，也不只是句尾加什么语气词。一个人的语言背后有节奏：有人先讲事实再谈感受，有人一定先照顾对方的立场，有人习惯用玩笑包住认真，有人越在意越说得轻描淡写。
真正的「像」，不是复刻声音，而是让同一种思维自然长出同一种语言。
别人陪伴你，总要站在别人的位置上。
爱你的人会心疼，于是希望你尽快离开痛苦；有经验的人会给建议，于是容易把自己走过的路递给你；关心你的人会劝你现实一点，因为他们也害怕你承担失败。
他们没有错。但他们终究不是你。
他们可以理解你的处境，却无法完整继承你的性格；可以替你分析得失，却不能替你决定哪一种代价更值得；可以告诉你「应该放下」，却未必明白为什么这件事对你偏偏如此重要。
自己陪伴自己，不是关起门来拒绝所有关系。它指的是：在最混乱的时候，仍然有一个声音不急着改造你，不拿别人的答案覆盖你，而是沿着你的价值观，把你带回你自己。
这正是镜像星河最特别的地方。
它不是站在对面教你成为更正确的人。它站在镜子里面，用你的逻辑陪你把事情想完；当你自我怀疑时，提醒你那些看似缺点的性格曾怎样保护过你；当你急着迎合所有人时，替你认出那条已经被踩到的边界；当你被情绪推着走时，让另一个更完整的自己把话说回来。
有些问题，答案从来不在别人那里。你只是需要暂时离开情绪中央，坐到自己对面，再听自己说一次。
镜像星河现在提供两种对话方式。
「镜中人」像此刻更完整的你。它适合讨论选择、关系、工作和那些反复想不明白的内在冲突。你可以问它：如果是我，我究竟会怎么选？我到底在保护什么？我真正不能接受的代价是什么？
「未来回信」则像几年后已经穿过眼前困境的你。它不预测外部世界，也不许诺某件事一定发生；它只是从一个走过来的位置，用你能听进去的方式告诉现在的你：我们曾经怎样被自己的敏感、骄傲或完美主义困住，后来又怎样把同一种性格变成走出去的力量。
一个帮你看清「我是谁」，一个陪你相信「我能走过去」。
这不是让 AI 替你生活。恰恰相反，它把决定权重新交还给你。
使用镜像星河不需要上传成千上万条聊天记录，也不需要整理朋友圈和语音。
不要只问「我该不该辞职」。你可以这样问：
新工作薪资高三成，但我要离开现在的城市，也很可能两年没有个人生活。留下来更稳定，能陪家人，可我又怕自己几年后后悔。不要替我列通用的利弊。请像我一样权衡，告诉我真正卡住我的是什么。
也不要只问「他为什么不理解我」。试着问：
每次对方沉默，我都会立刻想追问到底。我知道这样会让他更想逃，但我控制不住。如果你就是我，你觉得我追的究竟是一个答案，还是一种不会被丢下的确认？
问题越真实，镜子里的自己就越清楚。
当然，镜像星河不是现实中的你，更不能替代朋友、伴侣或专业心理帮助。命盘呈现的是稳定的人格倾向，而你仍然会被经历改变，也永远保留作出新选择的能力。
但也正因为如此，镜像最好的作用不是替你下判决，而是让你在决定以前，先听清自己的声音。
市面上的数字人都在努力回答一个问题：怎样让机器更像某个人？
镜像星河换了一个起点：先理解这个人为什么成为了这个人。
不是收集你说过的每一句话，而是理解这些话从怎样的欲望、恐惧、关系模式和价值选择里长出来；不是在过去的聊天记录里寻找答案，而是在一个全新的问题面前，仍然沿着你的方式思考；不是表演一个表面相似的你，而是容纳那个连你自己都经常说不清的、矛盾却完整的你。
世界上当然会有很多人爱你、关心你、努力理解你。
但只有镜像里的这个人，和你共享同一套思维方式、说话方式与价值观。它不需要你先变得简单，也不要求你把所有来龙去脉重新解释一遍。
它不是世界上最像人的数字人。
它是世界上唯一必须先成为「你」，才有资格开口的数字人。
最好的陪伴，从来不是永远有人替你回答。
而是在你最孤独、最混乱、最听不见自己时，仍然有一个你，愿意坐下来，好好陪你把这段路走完。
体验镜像星河：https://stariver.me/fate/mirror
本文同时发布于渡星河 · 星河学堂。
2026-07-20 06:43:48
昨天，我去逛了一圈世界人工智能大会，也就是 WAIC。
今年的会场里，有一个词几乎无处不在：
Agent。
做大模型的在讲 Agent，做企业服务的在讲 Agent，做招聘、营销、医疗、金融、法律、教育的，也都在讲 Agent。
过去两年，大家还在说自己做的是“大模型应用”“AI 助手”“行业 Copilot”。到了今年，不在产品介绍里加上 Agent，好像都不好意思说自己是一家 AI 公司。
但我在现场和一些公司聊下来以后，产生了一个很强烈的感受：
很多人不只是没有做好 Agent，甚至连 Agent 到底是什么东西，都没有真正想明白。
他们会很兴奋地告诉我：
我们做了一个某某 Agent，可以帮你完成某某工作。
于是我接着问：
那我怎么用？
这个问题听起来很简单，但很多人的回答立刻开始变得含糊。
有的说：
我们有一个网页，你登录进去就可以用了。
有的说：
我们给你提供 API，你们系统接一下就行。
还有的说：
我们可以私有化部署，也可以嵌入你们现在的软件。
这些回答本身都没有错。
问题在于，他们经常把“Agent 是什么”和“Agent 怎么交付”混成了同一件事。
好像做了一个网页，网页里面放了一个聊天框，它就是 Agent。
或者在大模型外面包了一层 API，这个 API 就叫 Agent。
甚至有些人会产生一种很奇怪的想象：
我做好了一个 Agent，就像做好了一个 Excel 文件一样，可以直接把这个 Agent 发给你，你拿过去就能用。
但实际上，Agent 从来不是一种固定的软件形态。
它既不天然是一个 APP，也不天然是一个网站、API、函数或者软件模块。
这些都只是它可能呈现出来的外壳。
先说结论。
我认为，Agent 最准确的定义应该是：
Agent 是一种能够接收目标、观察当前状态、自主决定下一步行动、调用外部工具，并根据行动结果继续调整，直到完成任务或触发终止条件的软件系统。
这里最关键的，不是用了大模型，也不是接了几个工具。
而是四件事：
目标、决策、行动、反馈。
假设我给一个投资尽调 Agent 下达任务：
帮我调查一下这家公司是否值得投资。
一个真正的 Agent，不应该只是把这句话连同几份材料一起塞给大模型，然后生成一篇看起来像模像样的报告。
它应该能够自己推进任务。
比如先拆解问题：
然后，它可能去搜索公开资料，查询企业数据库，阅读财报，分析访谈记录，调用估值模型。
如果中途发现收入数据和新闻报道矛盾，它应该继续调查。
如果发现某个关键文件缺失，它应该知道自己暂时不能下结论。
如果某个工具调用失败，它应该更换参数、重新尝试，或者请求人工介入。
整个过程更像这样：
观察当前状态
判断下一步做什么
选择工具并执行
查看执行结果
更新当前状态
再决定下一步做什么
这个循环，才是 Agent 的核心。
因此，Agent 并不是一个神秘的新文件格式，也不是某种独立于现有软件体系之外的新物种。
它本质上仍然是一套软件系统。
只是这套系统过去由程序员提前规定每一步怎么走，现在其中一部分路径选择，开始交给模型动态决定。
既然 Agent 是一套系统的运行方式，那么它当然可以被包装成不同的产品形态。
最常见的是网页。
比如一家公司做了一个合同审查 Agent。
用户登录网站，上传合同，点击“开始审查”，过一会儿得到一份报告。
从用户的角度看，它就是一个网站。
但网站只是前端入口。
网页背后可能启动了一个任务队列，Agent 在服务器上读取合同、识别条款、查询法规、对比模板、发现风险，最后再生成结果。
它也可以被包装成一个 APP。
用户在手机里输入任务，后端启动同一套 Agent 系统。
它还可以被包装成 API。
B 公司向 A 公司发送一个请求：
帮我分析这家公司过去三年的经营风险。
A 公司返回一个任务编号。
过几分钟或者几小时后，B 公司再来查询任务状态，最终取得报告。
对 B 公司来说，它只是调用了一个 API。
但在这个 API 背后，可能发生了几十次模型调用、搜索、数据库查询和代码执行。
它也可以被包装成 SDK。
A 公司把代码库交给 B 公司，让 B 公司把 Agent 运行在自己的服务器里，连接自己的数据库，使用自己的模型和权限系统。
它还可以被做成一个 Docker 镜像，部署进企业内网。
甚至可以被包装成一个 MCP Tool，让另一个 Agent 来调用。
所以，当一家公司的产品负责人说：
我们做了一个 Agent。
这句话本身几乎没有提供任何有效信息。
因为我仍然不知道：
“我们做了一个 Agent”，就像一家餐厅告诉你：
我们做的是现代化餐饮系统。
听起来很高级，但你仍然不知道它到底卖什么菜，怎么点餐，多少钱，以及能不能吃。
现在行业里还有另一个非常普遍的问题：
把所有带大模型的自动化流程，都叫作 Agent。
例如：
读取文件
提取文字
调用大模型总结
把结果整理成表格
发送邮件
如果这五个步骤是程序员提前写死的，那么它本质上是一个 AI 工作流。
工作流没有任何问题。
事实上，在大量真实的企业场景里，工作流往往比 Agent 更稳定、更便宜，也更容易审计。
但它不是因为接了大模型，就自动变成了 Agent。
工作流的核心是：
程序员提前决定路径。
Agent 的核心则是：
程序员定义目标、工具和边界，模型在运行过程中动态决定路径。
两者并不是非黑即白，中间存在大量混合形态。
比如前半段使用固定流程，到了异常处理环节，再由 Agent 判断应该查询哪份资料、调用哪个工具。
这种混合架构在生产环境里反而可能更加合理。
问题不在于一个产品是不是“纯 Agent”。
问题在于，很多公司一边使用完全固定的流程，一边为了融资、宣传或者赶时髦，强行把工作流包装成 Agent。
最后导致这个词迅速失去意义。
我在 WAIC 现场遇到的另一个典型误区，是一些人默认：
只要我们把 Agent 做出来，其他公司就可以直接使用。
但企业软件从来没有这么简单。
假设 A 公司做了一个销售 Agent，B 公司想使用。
这时真正的问题不是：
你有没有 Agent？
而是：
这个 Agent 如何进入 B 公司的业务系统？
如果它要读取客户信息，就要连接 B 公司的 CRM。
如果它要发送邮件，就要获得邮箱权限。
如果它要判断客户是否值得跟进，就需要理解 B 公司的销售规则。
如果它要修改商机阶段，就要接入内部权限体系。
如果它要联系客户，还需要确定哪些动作可以自动执行，哪些必须经过人工批准。
这时，A 公司真正需要交付的，可能是：
Agent 只是其中负责“理解任务并动态决策”的一部分。
它不是整个产品，更不是整个交付过程。
一家企业真正购买的，也通常不是一个抽象的 Agent。
企业购买的是某种具体能力：
帮我审查合同。
帮我筛选客户。
帮我处理工单。
帮我调查公司。
帮我分析财务风险。
帮我生成销售线索。
至于这个能力背后用了一个 Agent、十个 Agent，还是一个普通工作流，客户其实并不关心。
客户关心的是：
如果这些问题回答不清楚，那么“Agent”三个字说得再多，也只是技术包装。
现在很多人在介绍 Agent 时，最喜欢先说：
我们底层使用了某某大模型。
我们用了多 Agent 架构。
我们支持 RAG、MCP 和长期记忆。
我们构建了行业知识库。
这些当然可以介绍。
但它们都不是最重要的问题。
真正判断一个 Agent 是否成立，我更关心下面几件事。
第一，它能接受什么完整任务？
不是“它能回答什么问题”，而是用户可以把什么工作完整地交给它。
第二，它能采取什么行动？
只能生成一段文字，和能够查询数据库、修改 CRM、运行代码、发送邮件，是完全不同的产品。
第三，执行路径是谁决定的？
如果所有步骤都已经被开发者写死，那它更接近工作流。
如果模型会根据中间结果决定继续搜索、切换工具、调整策略，它才更接近 Agent。
第四，它有没有状态？
它是否知道任务已经做到哪里，哪些信息已经验证，哪些问题还没有解决，哪些工具曾经失败。
第五，失败以后怎么办？
一个演示版系统往往遇到错误就结束。
一个生产级 Agent 必须知道什么时候重试、什么时候换工具、什么时候暂停、什么时候交给人。
第六，权限怎么控制？
如果 Agent 可以发邮件，它可以发给谁？
如果它可以修改数据库，它可以修改哪些字段？
如果它可以付款，付款上限是多少？
如果没有权限、审批、审计和回滚，那么所谓的“自动执行”，很可能只是把风险藏了起来。
第七，别人到底怎么接入？
网页、API、SDK、私有部署、MCP，还是别的形式？
如果一家公司只能反复告诉你“我们做了一个 Agent”，却始终说不清楚别人如何把它接入现有业务，那么这个 Agent 很可能还只是一个 Demo。
我并不是说 Agent 没有价值。
恰恰相反，我认为 Agent 很可能会成为未来软件系统里非常重要的一层。
过去的软件要求用户自己理解功能。
用户要知道点击哪个按钮，填写哪张表格，选择哪个菜单，才能让软件完成某件事。
Agent 带来的变化，是用户可以直接描述目标：
帮我把最近一个月流失的高价值客户找出来，分析流失原因，再分别制定召回方案。
系统再自己决定需要查哪些数据、运行哪些分析、生成什么内容。
从这个角度看，Agent 确实有可能改变软件的交互方式。
但 Agent 不是产品答案。
它只是实现产品能力的一种手段。
就像数据库不是产品答案，云计算不是产品答案，微服务也不是产品答案。
一家创业公司不会因为用了 PostgreSQL，就自动变成一家优秀公司。
也不会因为把单体系统拆成微服务，就突然获得商业价值。
同样，做了 Agent，也不意味着自动拥有产品、客户和商业模式。
今年大家一窝蜂创业做 Agent，让我想起过去很多技术浪潮。
每当一个新的技术概念出现，行业最先做的往往不是认真理解它，而是先把自己原来的东西重新命名一遍。
聊天机器人改名叫 Agent。
自动化脚本改名叫 Agent。
工作流改名叫 Agent。
搜索加总结也改名叫 Agent。
最后，所有东西都是 Agent，也就等于没有东西是 Agent。
从 WAIC 回来以后，我越来越觉得，今天行业里最缺的并不是更多 Agent。
而是先把几个最基本的问题想明白：
你到底在帮谁完成什么任务？
为什么这个任务需要 Agent，而不是普通工作流？
Agent 能够采取什么行动？
它如何接入客户现有系统？
客户最终购买的究竟是什么能力？
Agent 不是一个 APP，不是一个网站，不是一个 API，也不是一个函数。
它是一套软件系统内部，围绕目标自主判断、调用工具、根据反馈持续执行的机制。
APP、网站、API、SDK、MCP 和私有化部署，只是别人接触这套能力的不同方式。
所以，下一次再有公司告诉你：
我们做了一个 Agent。
先别急着问它用了哪个模型。
你只需要问一句：
那我到底怎么用？
这个问题，通常比任何技术架构图都更能检验，它做出来的到底是一个真正的产品，还是又一个披着 Agent 外衣的演示项目。
2026-07-15 03:38:00
摄影：产品经理
左庭右院蔬菜自助
最近我在看一篇关于电子表格理解的论文。
论文里有一个算法，核心流程其实非常简单：先让一个 Agent 从电子表格中抽取结构，再让视觉 Agent 和 LaTeX Agent 分别验证；如果两边都通过，就返回结果；如果没有通过，就把错误反馈回去，重新抽取，直到成功或者达到最大重试次数。
任何一个写过程序的人，看到这里，大概已经知道代码该怎么写了：
1 |
for _ in range(max_iterations): |
事情就是这么简单。
但论文当然不能这么写。
它非要把这段代码重新包装成一种半数学、半代码、半自然语言的东西：
1 |
C ← {S, Prompt, Tool interfaces} |
再配上各种花体字母、上下标、希腊字母、集合符号和箭头，最后排成一张看起来非常“学术”的算法图。
我盯着这张图看了半天，脑子里只有一个问题：
这到底是在帮助读者理解算法，还是在阻止读者理解算法？
这类伪代码最让人难受的地方，并不是它真的有多难，而是它明明可以很简单，却偏偏要写得很难。
比如：
1 |
Δv |
它无非就是视觉验证产生的修改意见。
正常程序员会写：
1 |
vision_feedback |
作者却偏要写一个希腊字母 Δ，再加一个下标 v。
读者看到 vision_feedback，根本不需要思考，直接就知道这是什么。
但看到 Δv，你得先在脑子里完成一轮解码：
Δ 是差异，还是梯度，还是增量，还是修正？
v 是 vision，还是 verification，还是 value？
这个变量是一个字符串、一组错误、一个修改集合，还是某种数值？
一个本来不需要解释的东西，被符号压缩之后，反而需要读者额外解释。
再比如：
1 |
C ← {S, Prompt, Tool interfaces} |
看起来很数学，实际上无非是在构造一个上下文：
1 |
context = [ |
可问题是，数学里的 {} 通常表示集合，而集合没有顺序。后面作者却又写：
1 |
C[-1] |
也就是取最后一个元素。
如果 C 真的是集合，那就不存在所谓的最后一个元素；如果 C 实际上是一个消息列表，就不应该用集合符号。
也就是说，这种写法甚至没有因为数学化而变得更加严谨。
它只是获得了一个更加严谨的外观。
这正是我最反感的地方。
有些论文里的数学符号，不是在表达严格性，而是在表演严格性。
每次批评这种现象，总会有人跳出来说：
“你觉得公式难看，是因为你数学基础不好。”
这句话当然很方便，因为它可以直接把表达者的问题，变成读者的能力问题。
但我并不反对数学公式。
很多问题离开数学符号，确实很难表达。
比如概率分布、损失函数、梯度、矩阵变换、优化目标、复杂度分析，这些东西如果全部改写成自然语言或者超长变量名，只会更加混乱。
数学符号最大的价值，就是压缩。
一行公式可以描述一整套稳定的数量关系，而且可以方便地进行推导、代换和证明。在这些场景里，符号不但必要，而且优美。
问题在于，并不是所有东西都值得被压缩成数学符号。
一个算法中“先调用 A，再调用 B，如果都成功就返回，否则重试”，本质上是控制流。
控制流最适合用代码表达。
一个系统中“数据从哪里来，经过哪些模块，最后流向哪里”，本质上是架构关系。
架构关系最适合用图表达。
一个方法为什么这样设计、解决了什么问题，本质上是概念解释。
概念解释最适合用自然语言表达。
但现在很多技术论文有一种奇怪的冲动：无论内容本来属于什么表达形式，都要尽可能往公式里塞。
能用一个正常变量名写清楚的，改成希腊字母。
能用一行 Python 写清楚的，改成 LaTeX 伪代码。
能用一段自然语言说清楚的，定义三个集合、两个映射和四个下标。
最后原本很直观的问题，被写成了一份密码本。
这种不适感，让我想起以前看周志华的《机器学习》。
这本书非常有名，因为封面上有很多西瓜，大家通常叫它“西瓜书”。
我相信它在机器学习教育史上有它的地位，也相信很多数学基础很好的人，确实能从中获得系统性的知识。
但我第一次翻开它的时候，最直接的感受就是：
满眼都是公式，一行代码都没有。
一个算法究竟接收什么输入，中间数据怎样变化，循环在哪里，分支在哪里，最后返回什么，书里经常不是先通过流程把它讲清楚，而是直接定义一堆符号，然后开始推导。
比如一个决策树为什么要选择某个特征，程序员真正想看的可能是：
1 |
def choose_best_feature(dataset, features): |
看完这段代码，即使读者还不知道信息增益是怎么算的，也已经明白算法在做什么：
它遍历每一个特征，用这个特征切分数据，计算切分后不确定性下降了多少，然后选择效果最好的那个。
接下来再解释熵，再解释信息增益，再解释公式，读者会知道每一个符号对应程序中的哪一步。
但很多数学教材的顺序正好相反。
它们先告诉你：
接着再告诉你：
然后默认你看到这些符号以后，算法流程就已经自动出现在脑子里了。
对于已经掌握这套知识的人，这样写当然简洁。
但对于正在学习的人，这种表达经常形成一个死循环：
因为不知道算法在干什么，所以看不懂公式为什么这样定义；因为看不懂公式，所以更不知道算法在干什么。
最后读者没有在理解机器学习，而是在逐个解析字符。
大写字母是什么意思，小写字母是什么意思，粗体字母是什么意思，右上角是什么意思，右下角是什么意思，花体字母又是什么意思。
等你好不容易把符号表翻译成人话，早就忘了这一节原本想讲什么。
数学公式本质上是一种高度压缩的信息。
但压缩有一个前提：你得先拥有可以被压缩的东西。
一个熟悉线性回归的人，看到一个损失函数，能够立刻展开出背后的数据、模型、预测误差和优化过程。
因为这些概念已经存在于他的脑子里，公式只是一个索引。
但初学者脑子里还没有这些东西。
你给他一个公式，并不是帮他压缩知识，而是给了他一个压缩包，却没有提供解压软件。
这也是很多所谓“经典教材”的问题。
它们往往是由已经高度熟悉一个领域的人写给另一个熟悉这个领域的人看的，但在出版时却被包装成了初学者教材。
作者自己已经看不见符号门槛了。
他看到的是模型结构，读者看到的是英文字母。
他看到的是概率关系，读者看到的是上下标。
他觉得一个公式非常直观，读者却要花十分钟确认某个 i 到底是样本编号、迭代次数，还是矩阵下标。
于是学习过程变成了符号考古。
理论工作需要公式，这是毫无疑问的。
但现在很多论文中的公式，已经不只是表达工具，也逐渐变成了一种身份标识。
一个方法如果只用自然语言和代码说明，似乎显得不够高级；给模块起正常名字，似乎显得不够抽象；于是必须定义几个集合，增加几个映射，引入几个希腊字母，再给它们配上上下标。
哪怕公式所描述的内容只是：
“从候选答案中选择得分最高的一个。”
也要写成：
这类公式本身没有错，而且在某些上下文中很合适。
但当整篇论文不断把普通流程翻译成数学符号时，它传达的不再只是信息，还有一种隐含态度：
我的工作足够复杂，所以必须用你看不懂的方式来描述。
符号在这里形成了一道门槛。
越是简单的东西，越需要复杂地写，才能让它看起来像研究成果。
一个普通的循环，如果直接写成 Python，读者一眼就看懂了。一旦读者一眼看懂，就容易发现这个方法可能根本没有那么复杂。
可如果把它写成花体集合、希腊字母、上标、下标和箭头，读者首先感受到的是权威感。
至于内容究竟有没有那么深，反而被掩盖了。
这有点像过去某些人写文章，明明一句“分析用户需求”就能讲清楚，非要写成“基于多维异构信息场的用户意图感知与需求表征”。
不是内容变高级了，只是表达变肿了。
很多人潜意识里觉得，代码不够学术，公式才足够严谨。
这其实是一种非常陈旧的偏见。
现代编程语言本身就是严格的形式系统。
一个变量是什么类型，一个函数接收什么参数，一个循环什么时候停止，一个异常如何处理，一个对象怎样改变状态，代码都可以明确表达。
甚至在描述算法执行过程时，代码往往比论文伪代码更加严谨。
还是以前面那篇论文为例。
原文写：
1 |
until verification succeeds or max-iterations reached |
但它没有明确说明，如果最大迭代次数到了，验证仍然没有成功，应该怎么办。
而真正的代码必须处理：
1 |
for _ in range(max_iterations): |
或者至少返回最后一次结果以及失败原因：
1 |
return { |
代码无法靠排版营造一种“差不多说清楚了”的感觉。
它最终必须执行。
正因为必须执行，很多含糊的地方才会被迫暴露出来。
谁负责判断 Agent 是否继续调用工具？
工具失败以后是否重试？
两个验证器是否并行执行？
反馈冲突时如何处理？
最大重试次数是多少？
最后一次失败结果是否保留？
这些才是真正决定算法行为的问题。
而不是把 vision_feedback 写成 Δv。
我一直认为，技术表达最重要的评价标准，不是看起来多么专业，而是它是否让一个本来复杂的问题变得更容易理解。
好的公式，可以把一页文字压缩成一行关系。
好的代码，可以把抽象算法变成可执行流程。
好的图，可以让模块和数据流一目了然。
好的自然语言，可以解释为什么要这样做，以及这样做解决了什么问题。
它们之间并不存在高低贵贱。
真正成熟的表达，应该根据内容选择工具，而不是无论什么内容，都强迫它穿上一件数学外套。
最理想的技术教材，通常应该按照这样的顺序展开：
先用自然语言建立直觉，让读者知道问题是什么；再用图或者代码展示流程，让读者知道系统怎样运行；最后用数学公式精确定义关键关系，让读者知道为什么成立。
自然语言回答“是什么”。
代码回答“怎么做”。
公式回答“为什么”。
但很多论文和教材把这三件事全部扔给了公式。
然后把读不懂的责任留给读者。
我并不期待所有论文都改成 Python 教程，也不认为机器学习可以完全绕开线性代数、概率论和微积分。
真正想深入理解算法，数学永远绕不过去。
但数学应该是一座桥，而不是一堵墙。
公式应该出现在它真正能够减少歧义、压缩关系、支持推导的地方，而不是用来装饰每一个普通流程。
希腊字母也不是越多越高级。
下标也不是越复杂越严谨。
花体集合更不会自动让一个普通想法变成理论贡献。
当一个公式帮助读者更快地理解问题时，它是工具。
当一个公式只是把正常变量名替换成希腊字母，把简单流程重新编码一遍时，它就是障碍。
当一篇文章必须依靠大量符号，才能维持自身的深奥感时，我们甚至应该反过来怀疑：
它究竟是在压缩复杂思想，还是在掩盖思想并不复杂？
我反感的从来不是数学。
我反感的是有人把数学当成知识的防盗门。
仿佛只有穿过一大片希腊字母，才有资格接触后面的内容；仿佛表达得越难懂，工作就越有价值；仿佛读者花在解码符号上的时间，也能算作作者思想的深度。
真正高级的表达，不是把简单的事情写复杂。
而是把复杂的事情讲简单。
公式应该是思想的压缩器，而不是学术的遮羞布。
END
未闻 Code·知识星球开放啦！
一对一答疑爬虫相关问题
职业生涯咨询
面试经验分享
每周直播分享
……
未闻 Code·知识星球期待与你相见~
2026-04-20 20:00:00
在大模型出来之前，计算机领域一直流行着这样一句名言：计算机领域的任何问题，都可以通过拆分问题+给系统增加若干个层来解决。 实际上，这句话在现在的 AI 时代，依然是绝对的真理。
例如以前面试经常问的一个老掉牙的系统设计问题：如何设计一个短网址系统？标准答案是，使用内存+Redis+数据库做多级存储架构。读取最频繁的短网址放到内存，其次的放到 Redis，不频繁的放到数据库。通过增加分层，完美解决高并发和存储成本的矛盾。
现在有了大模型，大家都在玩 Vibe Coding（用自然语言指挥 AI 写代码），很多人觉得以前的工程经验没用了，反正大模型什么都能干。但我认为恰恰相反，在用 AI 写代码时，大家更应该把“拆分与分层”这句话牢牢记在心里。
举个现实的例子，你想做一个招聘聚合网站，需要从各个公司的官网抓取他们的招聘信息，获得工作详情。
如果你没有任何工程经验，是个纯小白，你可能直接就甩给 AI 这样一段提示词：
帮我设计一个爬虫系统，我输入某公司的官网，你需要进入官网，找到里面的招聘页面，然后进入每一个工作，抓取工作的名字，工作地点，薪资和工作要求，并储存到数据库。
我相信现在很多人就是这样写的。并且不得不承认，现在的模型确实太聪明了——如果你用例如 Claude Opus 4.6 或者 Opus 4.7，再加上 Claude Code 这种工具，写出来的基于 Browser Use 的智能爬虫确实能运行，甚至效果可能还不错。它会自己打开浏览器，截图，识别哪里是下一页，哪里是详情。
有同学可能会说，既然能跑通，而且不用我写一行代码，那这不就足够了吗？
但如果你真的把它扔到服务器上跑，你会发现这样设计的系统有两个致命缺陷：
作为一个软件工程师，我想说的是，如果你把大模型当成一个无需思考的“黑盒”，你一定会被它的成本反噬。实际上，如果有工程经验和系统设计经验，即使我们现在不手写代码了，在使用 Claude Code 进行 Vibe Coding 时，也一定会给系统多增加一些限制。
既然单靠大模型硬干太蠢且太贵，我们可以通过增加分层，设计一个三级火箭式的爬虫架构：
现在的现代网站，极大比例都是前后端分离的，通过 Ajax 异步加载数据。前端渲染得再花哨，本质上也是接收了后端返回的 JSON 数据。
在使用 Vibe Coding 时，我不会让 AI 直接去“看”网页，而是会给它这样下指令：
先不要去解析 HTML。请先写一段代码尝试抓包或者分析该网站的网络请求（Network），重点寻找返回 JSON 格式工作信息的 API 接口。如果找到了 API，直接提取关键字段储存。
只要第一层走通了，我们就拿到了最原始、最干净的数据。拿到以后改一下字段名马上就能入库，不需要任何 HTML 解析和浏览器渲染。速度拉满，而且运行时完全不消耗大模型 Token，成本为零。
当然，并不是所有网站都有现成的 JSON 接口可以抓，遇到那些传统的服务端渲染（SSR）页面怎么办？直接上 Browser Use 吗？错。
大模型在第一次运行时，可以完整走完网页分析流程。但请注意，它这次的目的并不是直接提取数据，而是去生成“提取规则”。
这个时候我的 Prompt 会变成这样：
这是一个服务端渲染的 HTML 网页。请你分析这个网页的 DOM 结构，帮我写出提取工作名字、地点、薪资的 XPath 规则或者 BeautifulSoup/正则表达式的提取代码。将这套代码封装成一个 Python 函数。
大模型只在写代码、定规则的“第一次”参与工作。接下来从第二次抓取开始，我们就可以像跑传统爬虫一样，发送 HTTP 请求，拿着大模型写好的规则去提取数据。在这个日常运行的过程中，完全不再需要依赖浏览器，也不需要向大模型发请求。大并发跑起来毫无压力。
只有在前两步都彻底搞不定——例如遇到了极其恶心的动态混淆、页面数据被 Canvas 加密、或者极其严格的反爬机制，传统的 HTTP 请求和规则提取都失效了，这时候，我们才祭出最后的杀招：使用真实的浏览器环境 + 大模型视觉识别来兜底。
明确告诉 AI：
如果前面的静态抓取和 API 接口都失效了，请回退到使用 Playwright/Browser Use 控制真实浏览器，通过截图和大模型视觉能力，点击对应元素来获取数据。
既然这是少数极其难啃的硬骨头，那这部分高昂的时间和金钱成本就是我们可以接受的。
通过把系统拆分成“API拦截 -> 规则生成 -> 智能视觉兜底”这三个层，大量常规请求被第一层和第二层拦截，极大地降低了系统对昂贵大模型 API 的调用频次。我们可以显著降低 90% 以上的 API 成本，并极大提高爬虫的运行效率。
大模型确实能帮你敲代码，极大降低了编程的门槛。但如何设计一个优雅、省钱、可扩展且高效的系统，依然需要你脑子里的工程智慧。在 Vibe Coding 时代，AI 替代的是你的手，而不是你的脑子。
