历史总是在重演,AI 时代的我们应该做些什么

很多公司以为自己接入了几个大模型,采购了一批智能体工具,员工就获得了某种近乎无限的生产力。

换个角度看:每个人突然多出了一百万名能力不稳定、缺乏上下文、不会主动澄清目标、偶尔虚构进度、还能高速消耗预算的下属。

这些下属不需要工位,也不会请假。它们一天可以提交上千次结果,看起来永远在工作。管理者很容易被这种吞吐量迷惑,误把生成速度当成有效产出,误把调用次数当成自动化程度,误把一段流畅的回答当成任务已经完成。

AI 把执行成本压得很低,同时把管理问题放大了。

今天的智能体系统可以被看成一种新型组织。模型是员工,token 是人力预算,上下文是岗前培训,工具权限是组织授权,工作流是汇报关系,评估体系是绩效制度,人工验收则对应管理责任。

按照这个视角观察,很多 AI 项目的失败也是情里之中。它们把模型能力当成唯一变量,却没有建立与之配套的管理系统。结果类似一家突然扩张到百万人的公司:招聘极快,职责模糊,没有培训,没有绩效标准,管理者还希望它自行涌现出秩序。

历史上,这类问题出现过。

铁路旧事

十九世纪三十年代的铁路热潮带来了前所未有的运输能力。铁路解决了距离和速度问题,也制造了规模、调度、协作和安全问题。

单条铁路容易运营。线路变长、车次增加、岗位分化以后,系统复杂度迅速上升。信息必须跨地区传递,车辆必须统一调度,责任必须分层,事故必须被记录和复盘。原有的管理方式无法支撑新基础设施的吞吐量,事故随之发生。

铁路公司最终补上的,是现代管理体系。

技术增加了系统能力,管理制度把能力组织成可持续的产出。铁路后来成为第一个十亿美元产业,支撑它的并非轨道和机车本身,还包括围绕大规模协作建立的组织结构。

AI 正在重演类似的路径。

过去的软件系统严格服从预定义逻辑。输入符合条件,程序进入对应分支。工程团队可以通过代码结构、类型系统、测试和运行指标逐层收紧系统行为。

智能体的行为边界宽得多。它可以搜索、分析、生成、调用工具、保存记忆、继续拆解任务。它也可能误解任务、忽略约束、重复调用、把猜测写成事实,在结果看似完整时掩盖中间步骤的错误。

当模型调用规模扩大,问题便从「它会不会回答」变成「我们怎样管理一支由概率模型构成的劳动力」。

许多企业仍在用采购软件的思路处理这件事:买更强的模型,开放更多上下文,增加 token 预算,再连接更多工具。

这很容易走向失控。

人海复现

遇到复杂任务就增加 token,和过去遇到项目延期就增加人手,逻辑高度相似。

管理者看到结果不好,第一反应往往是扩大上下文窗口,让智能体多思考几轮,再增加几个子智能体并行搜索。系统图越来越复杂,调用链越来越长,账单同步上涨。

问题可能出在任务定义上。

一个智能体收到「分析这家公司是否值得投资」,它需要自行猜测分析期限、风险偏好、数据范围、估值框架和输出用途。另一个智能体收到「优化系统性能」,它也要猜瓶颈位于吞吐量、尾延迟、内存占用、启动时间还是硬件成本。

人类员工面对这种指令,会追问。智能体更可能直接开始工作。它会用流畅语言填补任务中的空白,把未经确认的假设埋入推理过程,最终交付一份结构完整、目标偏离的结果。

给它更多 token,只会让偏离过程更长。

这和组织扩张中的人海战术没有本质差异。需求尚未稳定时增加开发人员,沟通路径随人数增长,信息损耗也随之增长。新增人员首先要理解问题,再理解已有方案,然后处理方案之间的冲突。最后,大量时间花在协调新增人力本身。

多智能体系统也会出现同样的问题。

一个规划智能体拆任务,多个执行智能体并行处理,汇总智能体负责合并,审查智能体再做验证。架构图确实很漂亮。但实际运行时,规划阶段的歧义被复制到所有分支,各个执行智能体基于不同假设工作,汇总阶段只能用更多 token 消解冲突。

最终系统花费大量计算资源,证明自己已经花费了大量计算资源。

智能体反复自我调用的循环尤其典型。表面上看,它在持续反思和改进;深入观察调用轨迹,常常会发现它没有获得新的外部信息,也没有引入新的判定标准,只是在几个近似答案之间改写措辞。

这种循环不会自然收敛。缺少验收条件时,「继续思考」没有终点。

工程上必须为循环设置退出规则:哪些指标达到后停止,连续多少轮没有新增信息后停止,成本超过多少后转人工,发生哪些工具错误后禁止重试。退出规则缺失,智能体就会把预算消耗当成工作进展。

上下文债务

几乎没人会给 AI 恰当的语境。

这句话听起来像提示词问题,实际涉及企业知识怎样存在、怎样更新、怎样被验证。

当一个人在公司里工作几年,会形成大量隐性知识。他知道某个字段名与实际含义不同,知道某项流程在文档里有三步、落地时有七步,知道某个客户的特殊约定,知道哪些数据能够使用,哪些结论虽然算得出来却不能直接发布。

这些知识分散在人的记忆、聊天记录、会议结论、历史工单和代码注释中。公司过去可以容忍这种状态,因为熟练员工承担了知识路由器的角色。谁遇到问题,找对人问一句即可。

AI 无法稳定获取这种语境。

把所有资料塞进上下文也解决不了。上下文越长,噪声越多;资料之间可能相互冲突;旧制度和新制度可能同时出现;局部例外可能被模型理解成通用规则。检索系统可以减少输入量,却无法自动判断哪份知识具备权威性。

上下文工程因此要处理四类问题。

第一类是范围。智能体完成当前任务究竟需要哪些信息,哪些材料只会分散注意力。范围太窄会漏掉约束,范围太宽会增加延迟和成本,也会提高错误引用的概率。

第二类是时效。文档必须带有版本、适用日期和失效条件。缺少这些元数据,模型很难区分现行规则与历史记录。

第三类是权威级别。制度文件、团队约定、个人经验和历史案例不能拥有相同权重。检索结果需要体现来源优先级,冲突时还要触发澄清或人工审批。

第四类是任务绑定。知识必须与执行步骤建立关系。把二十份文档交给智能体,让它自行判断何时使用,等于把一摞制度放到新员工桌上,然后要求他当天独立处理高风险业务。

上下文管理本身就是管理工作。它对应人类组织中的培训、制度建设和岗位说明。

企业在这里还会遇到政治阻力。

熟练员工掌握的独门知识,往往构成他在组织中的议价能力。让他把这些知识结构化地交给 AI,等于要求他亲手降低自身稀缺性。员工可能口头支持,实际只提交表层流程;关键判断仍保留在脑中,文档写得正确却无法操作。

靠宣传无法解决这种冲突。

知识沉淀必须进入正式职责,并与岗位价值重新绑定。贡献高质量规则、案例和评估集的人,需要获得与业务产出相当的认可。否则,组织一边要求员工共享知识,一边继续按照「不可替代程度」奖励个人,制度会驱动所有人保留信息。

AI 转型推进到深处,技术阻力通常会下降,组织阻力会持续上升。

冗员变形

传统组织里的冗员不一定完全不工作。他可能参加会议、整理材料、同步状态、反复确认,把时间消耗在缺少业务增量的活动上。

智能体也能制造同类繁忙。

大量 token 用于复述任务、生成计划、解释已经执行的步骤、重写已有答案。输出篇幅持续增长,新增信息却接近于零。调用记录看起来很丰富,真正影响最终决策的内容只占很小一部分。

「八成 token 什么都没做」虽然带有夸张色彩,却很接近许多智能体工作流的结构性问题。

衡量 token 效率不能只看输入输出数量。更合适的单位是有效决策增量:一次调用是否增加了新证据,是否排除了一个错误方向,是否完成了可验证的执行动作,是否降低了后续人工判断成本。

如果一轮调用没有完成以上任何一项,它大概率属于计算冗员。

企业很容易用平均调用成本掩盖这个问题。单次模型调用足够便宜时,团队会觉得多跑几轮无所谓。规模扩大后,浪费会在三个方向累积:直接推理成本、任务延迟,以及人工审查负担。

第三项经常被忽略。

智能体每多生成一份结果,人就多承担一份潜在验收工作。机器吞吐量可以在短时间扩大几十倍,人的审查能力没有同步扩张。最终形成新的队列:模型输出堆积,员工随机抽查,错误在未被发现的情况下进入下游。

这时再增加智能体,只会继续扩大待验收库存。

需要被放大的,是能够显著改变结果的「100 倍 token」。某次调用拿到了决定性证据,识别了关键矛盾,修正了任务边界,或者发现了会导致整条工作流失败的风险。这类调用数量很少,贡献却远高于普通生成。

寻找它们依赖调用追踪和结果归因。

每个工作流至少要记录:调用目的、输入来源、使用工具、产生的新信息、对最终结果的影响、失败类型以及人工修改位置。没有这套记录,团队只能看到账单和最终文本,无法分辨哪些调用有效,哪些调用只是增加长度。

这类似分析一个大型团队。只看员工人数和工作时长,无法判断组织效率。必须知道关键决策在哪里发生,哪些岗位形成瓶颈,哪些汇报关系制造重复劳动。

评估先行

管理智能体最有效的抓手是评估标准,也就是 evals。

编程成为 AI 当前最成功的应用场景,与代码天然具备可评估性有很大关系。程序可以编译或运行,测试可以通过或失败,性能可以测量,回归可以复现。模型生成的内容即使风格不同,也能被放入相对稳定的验证框架。

大量业务任务没有这种便利。

「研究一家企业」怎样算完成?

「生成高质量销售线索」中的高质量由谁定义?

「完成合同审查」需要发现哪些类型的风险?

「总结客户需求」允许遗漏哪些内容,又绝不能遗漏哪些内容?

企业如果不能回答这些问题,智能体也无法稳定交付。

很多团队先建设工作流,最后才补评估。他们把模型、检索、工具调用和记忆系统连接起来,跑出一批结果,然后组织专家凭感觉打分。几个版本之后,专家标准发生变化,历史结果无法比较,模型优化也失去方向。

评估应该早于大规模自动化。

任务进入智能体系统之前,先定义成功条件、失败类型和风险边界。评估集需要覆盖常规案例、边界案例、冲突信息、缺失信息以及必须拒绝处理的情况。只有理想样本的评估集,会把系统训练成演示环境里的优秀员工。

一个可用的评估体系至少分成四层。

第一层检查任务完成度。要求提取的字段是否齐全,要求执行的动作是否发生,输出格式是否符合下游接口。

第二层检查事实和证据。结论能否追溯到输入材料,引用是否支持对应判断,模型有没有用常识填补数据缺口。

第三层检查业务质量。结果是否符合领域规则,是否覆盖关键风险,是否达到能够进入下一流程的标准。

第四层检查运行效率。完成任务使用了多少 token、多少工具调用、多少时间,发生了多少次重试,人工修改比例是多少。

只评结果质量,系统可能通过十倍成本换取一点点效果提升。只评成本,系统又会通过减少分析步骤制造隐蔽错误。质量、成本和风险必须放在同一套评估里。

评估标准也不能永久固定。业务规则会变化,模型行为会变化,工具返回的数据结构也会变化。每次线上事故都应转化成新的评估案例。没有进入评估集的事故,后续很可能以相似形式再次出现。

这与人类团队的管理方式一致。OKR、质量标准、事故复盘和晋升要求,共同塑造员工行为。只给方向、不定义验收,最后只能依赖主管逐项盯人。

智能体同样需要制度化约束。

思想主权

AI 编程带来的另一个变化,是程序员的工作重心开始从逐行控制代码迁移到控制软件背后的想法。

模型一天能够生成数千行代码。开发者逐行审查全部输出,时间上已经不可行。即使坚持审完,也容易陷入局部细节:命名是否顺眼,函数是否拆得足够小,某段逻辑是否符合个人风格。

这些问题仍有价值,只是优先级下降了。

大模型擅长局部实现。给出清晰边界后,它可以完成函数、接口和测试,也能按照反馈快速调整。它对整体设计的把握更不稳定,尤其容易在多个局部合理选择之间拼出一个整体失衡的系统。

程序员必须控制设计意图。

数据结构为什么这样选择,状态由谁拥有,哪些不变量必须维持,失败后怎样恢复,性能目标是什么,哪些路径允许降级,哪些行为属于系统禁区。这些内容如果只存在于开发者脑中,AI 会用自己的概率偏好填补空白。

结果可能能运行,也可能通过局部测试,却难以演进。

控制思想要求开发者拥有足够深的系统理解。他需要判断某种设计会怎样影响内存布局、并发行为、故障边界和长期维护成本。只会写提示词无法完成这项工作。

vibe coding 最大的问题不在生成速度,而在责任链断裂。使用者描述一个模糊目标,模型生成实现,程序恰好能够运行,于是产物被视为完成。系统内部怎样工作、错误会在哪里积累、性能上限由什么决定,没有人掌控。

这种开发方式可以用于低风险原型。进入长期维护或高性能系统后,代价会快速暴露。需求变化一次,开发者无法判断应该修改哪一层;性能下降时,也不知道问题来自算法、数据结构还是调用关系。每次修改只能继续依赖模型猜测,系统逐步变成无人理解的代码堆积。

antirez 在开发本地 LLM 推理软件 DwarfStar 时,面对的是大量细微且会累积的错误。这类项目不能只看单个函数是否合理。一个局部误差、一处内存选择、一个数据结构上的偏差,都可能沿执行路径放大。

AI 在严谨设计和测试中可以提供很大帮助。前提是人掌握系统意图,知道该要求 AI 验证什么,也知道哪些结果不能接受。

代码审查也需要重新分配精力。

对于 Redis 这类大量用户会直接阅读和修改源码的项目,保持代码质量是对用户的尊重。审查仍然有意义。但如果开发者把全部时间用在检查每一行 AI 输出,QA、性能分析和下一步设计就会被挤压。

有限的人力应该优先投入故障模式、系统不变量、边界条件、性能退化和可维护性。代码风格可以交给自动化工具,重复性实现可以交给模型,局部错误可以由测试覆盖。设计责任无法外包。

设计文档

DESIGN.md 在 AI 编程环境中的地位会持续上升。

过去很多设计文档写于项目启动阶段,代码落地后很快过期。开发者最终以代码为准,文档只保留历史价值。AI 参与开发后,设计文档需要变成持续维护的系统接口。

它应该描述每个数据结构承担什么职责,关键实现技巧服务于什么目标,模块之间怎样协作,哪些不变量不能破坏,以及修改某部分时需要同步检查哪些路径。

模型阅读这样的文档,才能在修改代码前获取设计约束。当我们接手项目时,也可以先理解系统思想,再进入具体实现。

这并不意味着文档越长越好。把代码换成自然语言复述,价值很低。有效文档集中解释代码无法自行表达的内容:为什么选择这个方案,放弃了哪些方案,哪些行为依赖隐含前提,哪些性能特征必须保持。

文档还要进入变更流程。

如果代码改动影响数据结构、状态模型或失败处理,设计文档必须同步更新。评审时需要检查实现与文档是否一致。否则,AI 会依据旧设计修改新代码,错误会披着「遵循项目规范」的外衣进入系统。

设计文档可以视为给未来开发者和未来智能体准备的上下文。它承担组织记忆,减少关键思想只存在于少数人脑中的风险。

企业业务流程也需要同类文档。

流程说明不能停留在步骤列表。它要写清每一步的目标、输入、输出、判断依据、异常路径、升级条件和验收标准。只有这样,智能体才有可能承担稳定执行。

很多所谓 AI 落地难题,本质上暴露了企业从未把业务讲清楚。过去依赖熟练员工临场判断,这些模糊地带被人的经验掩盖。模型进入流程后,所有未定义部分同时暴露出来。

AI 没有制造这些混乱。它提高了混乱被复制的速度。

人的边界

AI 可以承担高吞吐的搜索、执行、分析和记忆管理。

搜索适合机器,因为它能在大量材料中并行查找候选信息;执行适合机器,因为重复流程可以被稳定调用;分析可以由机器生成多个假设和比较维度;记忆管理则可以通过检索、归档和关联降低人脑负担。

人需要保留四项责任:问题定义、歧义处理、风险判断和最终验收。

问题定义决定系统优化什么。目标写错,后续所有高效执行都会扩大偏差。

歧义处理决定何时允许模型自行推断,何时必须暂停并提问。完全禁止推断会让工作流频繁中断,完全开放推断又会把隐含假设带入结果。工程上应根据风险分级:低风险、可逆操作可以允许模型补全;高风险、不可逆操作必须要求显式确认。

风险判断需要结合业务后果。模型可以列出风险,却无法替组织承担责任。同样的错误,在内部草稿里可能只需重新生成,在合同、资金、生产系统和对外承诺中,影响完全不同。

最终验收意味着人要对结果负责。验收不能退化成快速扫一眼。模型输出量超过人的审查能力时,系统应限制吞吐量、增加自动评估或降低自动化范围。堆积大量无人验收的输出,没有形成生产力,只是形成了信息库存。

人机分工也不应按照「模型能做什么」设计。这个问题会随着模型升级不断变化。更稳定的划分方式是看责任和可验证性。

可验证、可回滚、低风险的任务,可以给智能体更大自治权。

结果可验证但动作难以回滚时,应增加审批点。

结果难以完整验证、错误影响又高的任务,AI 更适合作为分析和建议工具。

这套边界需要写进系统权限。只靠提示词要求模型谨慎,约束强度远远不够。工具层要限制可调用范围,工作流层要设置审批,运行层要保留审计记录,评估层要持续检查越权行为。

提示词属于沟通机制。权限系统才承担治理责任。

年轻工程师

我对年轻程序员是有些担心的,并非担心他们使用 AI,而是他们在建立心智模型之前就把实现过程全部交给 AI。

一个人没有亲手实现过解释器、数据库或哈希表,很难判断模型生成的实现在哪些地方存在结构性问题。他可能读得懂语法,也能运行测试,但无法推演数据怎样流动、状态怎样变化、性能为什么退化。

核对 AI 输出不能替代基础训练。

逐行检查一段自己并不理解的代码,只会制造虚假的参与感。更有效的训练方式是亲手实现规模受控的系统,遇到内存、并发、解析、索引和错误恢复问题,再用 AI 帮助验证思路、补充测试、寻找遗漏。

基础能力的价值还会上升。

代码生成越来越便宜以后,企业不会继续为普通代码行支付高溢价。能够定义系统、识别风险、设计评估、分析性能和承担技术决策的人,会掌握更大的杠杆。

年轻工程师如果只学习怎样让模型快速产出,能力会紧贴当前工具。模型更新一次,原有技巧可能迅速贬值。数据结构、操作系统、网络、数据库和编程语言建立的心智模型变化慢得多,它们决定一个人能否判断 AI 给出的方案。

高级工程师也不能因此停留在旧习惯里。

坚持所有代码都必须人工逐行编写,会把大量时间消耗在机器已经可以低成本完成的工作上。经验应该投入架构、约束、验证和复杂问题拆解。继续用代码行数证明专业性,和管理者用团队人数证明影响力没有太大差别。

管理重构

企业引入 AI 时,组织结构也要调整。

过去,一个经理管理十几个人已经接近沟通上限。未来,每个员工都可能拥有大量智能体。管理对象数量突然扩张,个人需要具备过去只有管理者才需要的能力:拆解任务、定义结果、提供上下文、设置检查点和处理异常。

工程师会越来越像技术经理。经理则需要理解评估、权限、成本和模型行为,单靠资源协调很难管理智能体劳动力。

团队流程也会变化。

需求评审需要增加可评估性检查。一个需求如果无法写出验收条件,进入智能体工作流后只会制造更多不确定输出。

架构评审需要关注智能体权限、上下文来源和失败路径。模型调用成功不等于业务任务成功,工具返回正常也不等于动作合理。

上线评审需要检查成本上限和停止条件。任何允许递归、自我调用或动态扩展任务的系统,都必须有预算约束。

事故复盘需要分析模型为什么做出对应行为,输入中缺少了什么,评估为什么没有拦截,以及权限设计是否允许错误继续扩大。把问题归结为「模型偶尔会犯错」,相当于铁路事故后只说机车存在风险。

采购更强的模型可能提升基线能力,却不会补齐管理缺口。模型越强,执行范围越大,错误的影响半径也越大。

AI 项目的成熟度最终会体现在几个问题上:

  1. 团队能否精确描述智能体负责的任务?
  2. 能否量化什么叫完成?
  3. 能否追溯结论来自哪些输入?
  4. 能否限制循环、重试和预算?
  5. 能否知道哪些 token 改变了结果?
  6. 能否在高风险动作前强制人工介入?
  7. 能否把线上失败转化成评估案例?
  8. 能否让设计思想脱离个人记忆,进入可维护的组织资产?

这些问题回答不出来,再复杂的智能体架构也只是一次昂贵的演示。

铁路时代的企业最终学会了管理速度、规模和复杂性。AI 时代需要处理的是概率行为、无限执行能力和有限人类判断之间的冲突。

我们已经拥有了数量近乎无限的数字员工。它们勤奋、便宜、速度极快,也缺少组织记忆、责任意识和稳定判断。

接下来的工作落在人身上:把问题讲清楚,把标准写出来,把权限收紧,把思想保存下来,对最后的结果签字。

这些都是基于当前模型能力和个人认知所作出的判断,随着时间的推移,也可能会涌现其它我当前所认知不到的,那又将是另一个世界。

以上。

使用 Vibe Coding 的这6 种后遗症,你有吗?

我已经很久没有沉浸式写代码了。

以前碰到一个复杂问题,我会花几个小时读调用链、画状态变化、跟踪异常路径。刚开始很慢,脑子里只有一些零散信息。随着上下文逐渐完整,代码会形成一张连续的结构图。再往后写,很多判断不需要反复查找,心流也就出现了。

现在的工作节奏完全变了。

我先给 Agent 描述需求,等它执行。等待期间又觉得空着可惜,于是打开第二个窗口,让另一个 Agent 补测试。看到还有时间,再开第三个任务处理重构。

十几分钟后,几个 Agent 陆续返回结果。我开始查看摘要、检查 diff、运行测试、补充要求、处理冲突。一个任务还没看完,另一个任务已经弹出完成通知。

一天下来,代码生成了很多,我却很少在同一个问题里连续停留半小时。

心流没了

Vibe Coding 最先改变的是注意力结构。

写代码原本是一种连续活动。理解需求、寻找入口、建立模型、设计实现、发现问题、修正判断,这些环节彼此相连。Agent 把它切成了很多轮对话:描述任务,等待结果,检查结果,再描述下一步。

每轮都很快,每轮都带来一点进度。

大脑很容易适应这种高频反馈。问题一旦需要长时间推演,我就会产生阻力。以前遇到难点,会继续读代码、查日志、进调试器。现在的第一反应经常是把问题发给 Agent,让它先分析一下。

思考开始变得外包化。

这不会让工程师立刻失去能力。更常见的变化是耐心下降。看十分钟调用链就想问 AI,调试几次没有结果就想换提示词,设计还没收敛就开始生成代码。

慢思考越来越难维持。

复杂工程问题偏偏依赖这种能力。并发状态、数据一致性、故障恢复和性能瓶颈,很少能靠几轮快速问答解决。它们需要人在同一套上下文里待得足够久,直到各种局部信息连成一体。

Agent 使用频率越高,我越忙,也越难进入这种状态。

Token 焦虑

额度快用完会焦虑,这很正常。额度没用完也会焦虑,就就有点奇怪了。

买了订阅,看到 token 还剩很多,会产生一种浪费感。离开工位之前,总想再布置一个任务。准备去开会,让 Agent 先跑一轮测试;准备吃饭,让它顺手整理模块;睡觉之前更容易上头,总觉得应该给 AI 加个通宵夜班。

真的是如群友所说:床前 token 光。

这种焦虑会慢慢改变任务优先级。原本没有必要立即处理的工作,因为 Agent 正好空闲,被提前塞进了队列。需求还没有想清楚,先做一个版本看看;某段代码虽然还能维护,先让 Agent 重构一下;测试已经够用,再补几十个用例似乎也没坏处。

Agent 忙起来了,人的待验收任务也堆起来了。

第二天早上打开电脑,几个任务全部显示完成。看起来像是白捡了一夜生产力。仔细检查才会发现,每个结果都需要重新加载上下文,都要判断实现边界,还要验证它有没有把局部问题扩展成新的抽象。

AI 上完夜班,我们开始加班验收。

更麻烦的是,等待结果本身也会占据注意力。人已经离开电脑,脑子里还惦记着任务有没有跑完、会不会失败、明天要看多少改动。休息时间变成了一段漫长的异步等待。

越用越累

刚开始用 Vibe Coding,我以为自己会轻松很多。实际体验是产出提高以后,疲惫感也跟着上升。

过去一天写两百行关键代码,我基本知道每一行为什么存在。现在几个 Agent 可以快速生成几千行改动。我的工作量没有消失,它从编写转移到了理解、判断和验收。

生成可以并行,理解通常只能串行。

一个 Agent 修改接口,一个 Agent 补充测试,另一个 Agent 调整调用方。它们各自都能完成任务,最后所有结果汇集到我这里。我需要判断接口语义有没有变化,测试是否沿用了错误假设,调用方有没有掩盖异常,几个改动能否同时成立。

机器的带宽增加了,人的带宽没有同步扩展。

当输出超过处理能力,审核质量会自然下降。最初还会逐行看 diff,后来只看摘要;最初会认真检查测试内容,后来看到绿色就继续;最初要求自己理解每个关键决策,后来开始依赖 Agent 提供的变更说明。

疲惫带来的危险,很少表现为明显的错误决定。它更像一种缓慢降低的验收标准。

每一次都只少看一点,每一次都觉得风险可控。几个月以后,代码库里已经出现大量没人完整理解的实现。

不想 review

我现在越来越不想看 AI 写的代码。

人工审核 AI 代码,有时比自己重写还累。自己写代码时,设计过程和实现过程是连续的。我知道哪些地方经过权衡,哪些地方只是临时处理,哪些假设需要后续验证。

面对 AI 生成的代码,这些上下文都要重新推导。

最让人疲惫的代码,往往还写得挺像样。命名规范,结构完整,注释齐全,测试也有。逐段看都有合理性,放回整个系统却经常显得多余。

一个边界条件被扩展成通用框架,一次局部修复引入新的中间层,三个表面相似的流程被强行抽象到一起。代码能运行,测试也能通过,但维护成本被悄悄推高了。

审核者需要花很大力气,才能解释为什么一份「正确」的代码不适合进入当前系统。

重复几次以后,人会开始逃避。既然测试过了,先合进去。出了问题,再让 Agent 修。下一次 Agent 又基于上一次生成的结构继续扩展,代码越来越多,理解越来越少。

最后会出现一种荒诞状态:人不愿意维护 AI 写的代码,于是继续让 AI 维护。

理解变浅

亲手写代码的过程,本身也是建立系统认知的过程。

为了实现一个功能,我需要找到入口,理解依赖,处理编译错误,观察测试失败,再确认数据如何穿过整个链路。实现完成以后,我对这部分系统已经形成了自己的判断。

Vibe Coding 跳过了其中大量过程。

Agent 告诉我改了哪些文件、采用了什么方案、测试结果如何。我可以很快获得一份完整说明,却没有经历那些失败、试探和修正。知道结果,与掌握系统之间,仍然隔着很长一段距离。

这种认知缺口在日常迭代中不容易暴露。Agent 还能继续修改,功能也能继续上线。等到线上故障、复杂重构或性能退化时,团队需要在压力下定位根因,欠下的理解成本才会集中出现。

每个人都参与过系统开发,问到关键链路却只能讲出局部。继续追问异常如何传播、数据如何恢复、容量边界在哪里,回答逐渐变成「让 Agent 分析一下」。

工具还在,工作可以继续。工程师对系统的控制感却在下降。

调度上瘾

多 Agent 会带来很强的生产感。

屏幕上同时跑着几个任务,状态不断变化,代码持续生成。即使我没有处理最困难的问题,也会觉得今天推进了很多工作。

这种感觉很容易上瘾。

我开始热衷于拆任务、写提示词、查看进度、追加要求。一天都在操作,一天都没有停下来。到了晚上,任务列表关闭了不少,却很难指出自己完成了哪段连续思考。

技术管理者更容易陷进去。我们的时间本来就被会议、消息和协作切碎,Agent 又提供了一种产出感很强的碎片化工作。它比回复消息更像研发,比真正做架构设计轻松,还能持续制造「事情正在推进」的反馈。

久而久之,启动任务替代了处理问题,完成数量替代了工程质量。

代码还在,人却远了

Vibe Coding 让我写得更快,也让我离代码更远。

这种距离很难通过提交数量看出来。功能持续上线,测试数量持续增加,仓库每天都很活跃。只有在关掉 Agent、独自面对系统时,才能感受到变化。

我还能不能连续读一小时代码?

能不能在没有摘要的情况下说清楚一次变更?

能不能独立判断某个抽象该不该存在?

线上出问题时,我脑子里有没有完整的执行链路?

这些问题比 token 使用量更让我焦虑。

我仍然每天使用 Vibe Coding,也很难再回到完全手写的状态。它确实提高了生产速度,只是这份速度附带了一组后遗症:心流消失、注意力碎片化、token 焦虑、审核疲劳、理解变浅,以及对调度和即时反馈的依赖。

以前写代码会累,累在实现。

现在也累,累在持续接收、持续判断、持续验收。机器一直在输出,我的大脑一直没有真正下班。

以上。

做 Agent 架构时,OpenViking 的几个可以学习的点

设计 Agent 架构时,有一个模块的边界经常画不清晰:上下文。规划、工具调用、执行循环这些组件的职责都好切分,唯独「Agent 该知道什么」这件事,散落在 prompt 模板、RAG 管道、记忆插件和会话历史四个地方,各管一段,互不通气。

比较常见的状态是知识走一条 RAG 管道,用户记忆走一个独立的 memory 服务,工具使用经验干脆没有沉淀机制,靠 system prompt 里手写的几条注意事项撑着。跑长周期任务时问题集中爆发:第三十轮时 Agent 忘了第五轮的约束;召回了一段错误文档,事后想归因,向量库只给一个相似度 0.83,别的什么都没有。

这两个 case 背后是同一个架构缺陷:上下文没有被当作一个独立子系统来设计,它只是若干条数据管道的松散集合。

最近把火山引擎开源的 OpenViking 看了一遍,它把自己定位成「面向 AI 智能体的上下文数据库」,GitHub 上 27.2k star。这个定位本身就是一个架构主张:上下文应该是 Agent 架构里一个有统一接口、有存储模型、有检索语义、可观测的独立组件,地位类比业务系统里的数据库。

沿着这个主张往下拆,它有几个设计决策对做 Agent 架构的人有一些参考价值。

统一存储模型

Agent 架构里第一个要回答的问题:记忆、知识、技能这三类上下文,存储模型是分开还是统一。

分开是多数团队的现状,也是我们踩过的坑——三套 schema、三套检索接口、三套更新逻辑,Agent 侧要维护三种访问心智。OpenViking 的选择是统一:全部抽象成文件,挂在 viking:// 协议下的虚拟文件系统里,每个条目一个唯一 URI。它给出的目录结构:

viking://
├── resources/              # 资源:项目文档、代码库、网页等
│   └── my_project/
│       ├── docs/
│       │   ├── api/
│       │   └── tutorials/
│       └── src/
└── user/
    └── {user_id}/
        ├── memories/
        │   └── preferences/
        │       ├── writing_style
        │       └── coding_habits
        ├── resources/
        │   └── private_project/
        ├── skills/
        │   ├── search_code
        │   └── analyze_data
        └── peers/
            └── web-visitor-alice/

Agent 用 lstreefind 浏览自己的上下文。

从架构角度来看,这个统一带来两个收益。第一,定位从概率性变成确定性。扁平向量库里想精确更新某个用户的编码习惯记忆,只能靠 metadata filter 打补丁;文件系统里就是一个路径寻址,viking://user/{user_id}/memories/preferences/coding_habits,增删改查全部确定。多租户隔离也顺带解决了——user/{user_id} 这层目录天然就是隔离边界,商业版文档里明确把多租户共享和隔离列为核心场景。

第二,Agent 与上下文之间的接口收敛成了一套文件操作原语。这一点对架构的影响比看起来大。我们之前自研记忆系统时设计过一套 memory.query(scope, filter, ...) 风格的 API,模型调用的出错率明显高于让它直接操作路径。文件系统是 LLM 预训练语料里高频出现的心智模型,lstree 的语义模型天然理解,不需要在 prompt 里教。接口设计顺着模型先验走,省下的是持续的 prompt 工程成本。

代价在写入侧的分类决策。内容归置到哪个路径,做错了后续检索会系统性偏航,扁平向量库至少没有「放错文件夹」这种失败模式。OpenViking 靠写入时的自动语义处理来做归置,这个环节的质量上限决定了整棵文件树的可用性,我认为是它工程上最脆弱的一环。

预算分层供给

第二个架构问题:上下文以什么粒度供给给模型。

传统 RAG 的答案是 chunk 全量——检索 top-k 塞进 prompt,k 靠拍脑袋。这在架构上等于把上下文预算的管理责任丢给了一个魔法数字。OpenViking 的方案是写入时预计算三层表示:

  • L0(摘要):约 100 tokens,一句话总结,快速判断相关性
  • L1(概览):约 2k tokens,核心信息和使用场景,供规划阶段决策
  • L2(详情):完整原始数据,确有必要时才读

每个目录也带自己的 .abstract.overview,Agent 读任何完整文件之前,先花 100 个 token 判断这个方向值不值得深入。

放到 Agent 的执行循环里看,这三层恰好对应了三个阶段的信息需求:候选筛选阶段用 L0 扫一遍,规划阶段对少数目标加载 L1,执行阶段只对必要条目读 L2。上下文供给从一次性的赌博变成了跟随 Agent 决策流程的渐进加载,粒度和阶段对齐了。

数据上,OpenViking 0.3.22 在 LoCoMo 长对话记忆评测里,三种 Agent 集成的准确率到 80–83%,原生记忆只有 24–57%;输入 token 减少 34.3%–91.0%,查询时延降低 58.45%–66.10%。token 降幅区间这么宽,说明收益高度依赖任务形态:判断型任务能省九成,需要全量细节的任务省不了多少。评测脚本在仓库 ./benchmark 目录,可自行复现。

架构上的 trade-off 转移到了写入路径。L0/L1 由模型生成,每次数据摄入都有一笔推理开销,且是异步的——README 明确提示 add-resource 不加 --wait 时语义处理需要等待。写入吞吐敏感或数据高频变更的场景,这条路径会成为瓶颈。更隐蔽的风险是摘要写歪:L0 错了,后续所有基于它的相关性判断连带出错,等于在检索链路最上游埋单点。官方提供 ov reindex <uri> --mode semantic_and_vectors 重新生成语义产物再刷新向量,说明他们自己也预期摘要需要返工。

即便不引入 OpenViking,「写入时预计算多粒度表示、按 Agent 决策阶段供给」这个模式可以直接抄进自建架构。

检索即导航

检索组件在 Agent 架构里通常被实现成一个无状态函数:query 进,top-k 出。OpenViking 把它改成了一个有过程的导航。

先通过意图分析生成多个检索条件;向量检索定位初始切片所在的高分目录;在该目录下二次检索,高分结果更新进候选集;有子目录就逐层递归;最终返回最相关的上下文,连同周边语境一起。

一句话概括:先锁定高分目录,再向下精细探索。

这解决的是扁平 top-k 在 Agent 场景下的一个结构性缺陷——碎片没有语境。命中一个 chunk,Agent 不知道它前后是什么、属于哪份文档的哪个章节,拿到的是信息孤岛。导航式检索的返回结果自带位置和邻居:这段内容出自 API 文档的鉴权章节,同目录下还有 endpoints 说明。对代码库问答这类强依赖结构的任务,这个差异是决定性的。

代价:多轮向量查询加上可能的多次判断,单次检索的绝对延迟一定高于一把梭的 ANN。前面提到的时延降低 58%–66%,我的理解是端到端口径——省下的 token 让生成阶段变快,摊平了检索阶段的开销。架构选型时要按流量形态判断:Agent 任务型场景,单次任务价值高、容忍秒级检索,划算;高 QPS 低延迟的在线检索,这套递归策略不合适。

全链路留痕

Agent 架构的可观测性讨论,通常止步于工具调用日志。OpenViking 把留痕做进了检索内部:每次查询都保留完整的目录浏览轨迹,结果不对时能看到它出自哪条路径。

做过 RAG 生产运维的人知道 bad case 归因有多难。用户投诉答案错了,排查下来只能看到「这几个 chunk 相似度最高所以被召回」,正确内容为什么没进 top-k,向量空间不会解释。最后退化成调 embedding、调 chunk 大小、调 k 值的炼丹循环。

轨迹留存把归因变成可逐步 debug 的过程:检索在哪个目录拐错了弯、哪一层的 L0 摘要误导了判断,路径上每一步可查。修复动作随之有了着力点——重写某个目录的 abstract,或者调整文件归置,都对应到具体操作。配套的 OpenViking Helper 桌面端(Beta,支持 macOS 和 Windows x64)能解析 Claude Code、Codex、Trae 的会话,展示召回、Prompt 注入、MCP 调用、捕获和提交事件,Agent 与上下文系统之间的全部交互摆在明面上。

这一条我建议所有做 Agent 基础设施的团队照抄,无论用不用 OpenViking:把「检索决策可回放」写进架构的非功能需求。存储和埋点的成本,第一次生产事故排查时就能收回来。

经验回写闭环

多数 Agent 架构是开环的:任务执行完,除了对话历史什么都不留,下次遇到同类任务从零开始。OpenViking 在架构里补了一条回写路径:会话通过 session.commit() 显式提交后,系统异步提取两类内容写入长期记忆——用户偏好,和 Agent 经验,落到对应的 /memory 目录下。

用户偏好各家都在做。Agent 经验这条更值得看:从任务执行结果里提取操作技巧、工具使用经验,供后续同类任务复用。tau2-bench 的数据:经验记忆让任务成功率在 Retail 提升 6.87 个百分点,Airline 提升 11.87 个百分点,对比同一 LLM 无记忆基线。模型没动,纯靠架构里加一条经验沉淀回路,拿到两位数以内的成功率增量。

对比另一条提升路线——攒数据做 SFT 或 RL 微调,周期以周计,成本以万计。经验记忆改的是上下文而非权重,迭代周期是每次会话。两条路线不互斥,但在架构演进的排序上,外置经验回路的边际成本低得多,应该排在微调前面。

两处要留神。一是提取质量:异步抽取本身是 LLM 调用,抽错等于往长期记忆注入脏数据,且脏记忆会在后续任务里持续生效,危害大于一次性的错误回答。二是显式 commit 这个设计——记忆更新由开发者主动触发而非全自动,「哪些会话值得沉淀」的裁量权留在应用层。我们内部一度想做全自动沉淀,现在倾向于保留这个开关,至少在提取质量有验证机制之前。

接入成本

把这套东西放进现有 Agent 架构的成本,不高。

Python 3.10 以上,pip install openviking --upgradeopenviking-server init 走交互式向导——支持火山引擎、OpenAI、Codex OAuth、Kimi、GLM 和本地 Ollama,选 Ollama 还能按硬件拉合适的模型。openviking-server doctor 启动前体检配置、Python 版本、提供商连通性和磁盘空间。有官方 Docker 镜像和 Helm 部署。

集成面很宽:Claude Code、Codex、OpenClaw、Hermes、Cursor、Trae、OpenCode、pi、MCP 客户端、LangChain / LangGraph 都有官方接入,集成做的事是把召回注入 Agent 上下文并自动提交会话记忆。如果你的架构本来就走 MCP 或 LangGraph,接入成本主要在配置层。

许可证要过法务。主项目 AGPLv3,crates/ov_cli 和 examples 是 Apache 2.0。AGPLv3 自用没问题,基于它对外提供网络服务会触发传染性条款的开源义务。商业版 OpenViking Service 承诺与开源版共享同一套代码内核,差异在托管运维、基于 VikingDB 的规模(宣称万亿级向量、百亿数据毫秒级检索)、SLA 和企业级安全合规,有至多 50 个文件的免费试用和迁移工具。开源版默认本地存储加单机向量引擎,数据规模上去后的可靠性要自己扛,架构容量规划时要计入。

背后有论文支撑:VikingMem(arXiv:2605.29640),已被 VLDB 2026 接收,开源版实现了论文描述的部分核心能力。团队在按数据库系统的标准做存储和检索设计,这在 Agent 记忆类项目里少见。

需要注意的点

三点。

其一,整个体系的地基是写入时的自动语义处理——摘要、概览、目录归置全靠模型生成,这些产物没有质量下界。LoCoMo 和 tau2-bench 覆盖的场景有限,换到术语密集的企业知识库,L0 摘要的准确率会不会崩,要拿自己的真实数据验证,别信 benchmark 直接上生产。

其二,导航式检索的延迟特性划定了适用边界,架构选型时按流量形态判断,前面说过了。

其三,项目还早,README 自己承认「要做的事还很多」。1813 次 commit、92 个 open issue、320 个 PR,迭代活跃,反面是 API 稳定性存疑,核心链路重度依赖它要做好跟版本的准备。

回到 Agent 架构本身。「上下文作为独立子系统」「统一文件存储模型」「按决策阶段分层供给」「检索决策可回放」「经验回写闭环」,这五个设计每一个都能脱离 OpenViking 独立存在。

以上