梁文锋的 52 条语录，给 Agent Development 的 6 个工程启发

导语

最近读到一份《梁文锋四小时投资人会议实录》的语录整理。

整理者一共收集了 52 条内容，涉及 AGI、Agent、持续学习、模型成本、开源、商业化和团队管理。需要先说明：这不是公开的完整逐字稿，整理者也注明，部分词句在保留原意的基础上可能与原话略有出入。

因此，这篇文章不打算逐句解读，也不准备把一家模型公司的选择直接变成所有团队都该遵守的方法。

我更关心的是另一个问题：

如果把这些判断放到 Agent Development，也就是 Agent 开发领域，哪些部分能够转化成具体的工程原则？

过去一段时间，Agent 项目很容易沿着同一条路膨胀：先接模型，再加搜索、浏览器、记忆、知识库、定时任务和多 Agent。功能越来越多，系统看起来越来越像一个“超级助手”，但最初要解决的那件事反而说不清了。

梁文锋在语录里反复提到主线、克制、成本和“做成的概率”。这些词放到 Agent 开发里，指向的其实是同一个问题：

一个 Agent 的成熟，不在于它会多少种动作，而在于它能否持续把核心任务做完，并且让结果可以检查。

沿着这条主线，我整理出六点值得 Agent 开发者借鉴的地方。

一、先确定唯一主线，再用真实工作验证它

语录里有一句很直接：DeepSeek 只有一条主线。

3D、视频生成、多模态产品和超级 App 都可能有价值，但如果不能提高实现核心目标的概率，就不应该同时消耗主要资源。

Agent 项目尤其需要这个判断。

因为 Agent 可以连接的能力太多了。模型、MCP、浏览器、代码执行、文件系统、记忆和多 Agent 协作，每一样都很有吸引力。问题是，这些能力接进来以后，不会自动组成一个可靠产品，只会扩大系统能够出错的范围。

对一个 Agent 来说，“主线”至少要回答三个问题：

它替谁完成什么任务？
最终交付物是什么？
怎样判断这次任务真的完成了？

例如，一个代码审查 Agent 的主线不是“理解代码并给出专业建议”，而可以写得更具体：

输入：一次代码变更及相关仓库上下文。
输出：按严重程度排列的缺陷清单，每条包含文件位置、原因和修复建议。
完成标准：不引用不存在的代码；高风险问题有代码或测试证据；没有发现问题时明确说明检查范围。

在这条主线还没有跑稳之前，长期记忆、自动修复、多仓库检索和多个审查 Agent 并行工作，都不一定是下一步。

语录里还有一个容易被忽略的判断：下一代模型首先要让 DeepSeek 自己用得好，帮助团队开发更前沿的模型，然后才是让更多用户觉得好用。

对 Agent 团队来说，这对应的是 Dogfooding，也就是先在自己的真实工作中持续使用产品。

演示环境里的 Agent 往往输入完整、权限充足、工具不会超时。真实工作会暴露另一套问题：上下文缺失、文件命名混乱、任务中途变化、工具返回空结果、人工需要接管。团队自己每天使用，才能积累这些失败记录，知道主线究竟卡在哪里。

因此，第一个用户不一定要多，但必须真实。先找一类团队每天都要完成、结果可以验收的任务，让 Agent 连续跑一段时间，再决定是否扩展到更多场景。

更实用的做法，是给项目写一张 Stop Doing List：

暂时不做与核心交付无关的入口；
暂时不增加无法单独验收的能力；
暂时不用多 Agent 解决单 Agent 已经能稳定完成的问题；
暂时不把偶尔使用的功能塞进每次运行的上下文；
暂时不因为演示效果好，就默认它适合生产环境。

这不是保守，而是在保护主线。

二、愿景必须落到验收条件，而不是只写进 System Prompt

梁文锋谈愿景时说，愿景不是挂在墙上的标语，不是怎么说，而是怎么做。

换到 Agent 系统里，这句话同样成立。

很多 System Prompt 会写：

你是一个准确、可靠、负责任的智能助手。
请认真完成任务，不要编造信息，确保用户满意。

这些话方向没有错，但系统不会因为多写几次“准确”和“可靠”就真的可靠。

如果准确很重要，就要让结论能够追溯到来源；如果安全很重要，就要让高副作用操作经过权限检查；如果完成质量很重要，就要在返回 done 之前检查真实产物。

也就是说，价值判断最终要变成可执行的系统边界：

抽象要求	工程实现
不要编造	关键结论保留来源；引用文件前检查路径和内容是否存在
保证安全	删除、发布、付款和外部写入在运行时拦截并请求确认
认真验证	修改代码后运行相关测试；生成文章后检查引用、配图和排版
完整交付	用文件、Patch、测试结果或草稿编号证明任务已经完成
尊重用户	只在缺失信息会显著改变结果时追问，低风险信息可以说明假设后继续

这也符合 GPT-5.6 的 Prompt 思路：少规定模型必须怎样思考，多定义最终结果、证据、边界和停止条件。

一份 Prompt 只有在改变了 Agent 的行动或验收方式时，才真正成为系统设计的一部分。

同样，Eval 分数也不能代替愿景。评测应该检查用户真正需要的结果，例如缺陷有没有被发现、报告能否复核、发布物是否可用。为了提高一个脱离真实任务的分数而优化 Agent，只是把墙上的标语换成了排行榜。

三、把幻觉当作产品问题，不要只等下一代模型解决

语录把幻觉归为产品问题。这一点对 Agent 开发很重要。

模型能力继续提高，幻觉可能减少，但 Agent 的错误不只来自“模型记错了事实”。它还可能：

调错工具；
读错工具返回；
把空结果理解成成功；
引用不存在的文件；
在只完成一部分时宣布任务结束；
把网页里的恶意指令当成用户要求；
使用过期信息做当前决策。

这些问题不能只靠换一个更强的模型解决。

可靠的 Agent 需要一条证据链：

流程图

其中，模型负责判断和选择动作，系统负责提供硬边界和可观察结果。

例如：

搜索结论要保留来源 URL；
代码修改要能看到 Patch；
数据分析要保留查询条件和计算口径；
发布任务要返回真实草稿编号；
高风险工具必须经过运行时权限检查；
Agent 声称完成时，要检查目标文件或外部状态是否真的存在。

“不要幻觉”是一句提醒。让错误更容易被发现和阻断，才是产品能力。

四、真正该优化的是单次有效交付的成本

梁文锋把模型竞争的差距概括为成本、时间和用户体验，并把成本放在第一位。

Agent 系统也应该看成本，但不能只看每百万 Token 的价格。

一次任务的真实成本至少包括：

模型输入和输出 Token
+ 搜索、浏览器、代码执行等工具费用
+ 失败重试
+ 任务延迟
+ 人工检查和返工

一个便宜模型如果经常选错工具、重复搜索或者需要人工重做，最终可能比贵模型更贵。一个推理能力很强的模型，如果被用来处理简单格式转换，也是在浪费资源。

因此，模型路由应该围绕“完成一类任务需要多少钱”，而不是“哪个模型单价最低”：

低风险、可批量验证的工作，优先使用成本更低的模型；
需要复杂判断或长链路规划的关键步骤，再调用更强模型；
能用脚本稳定完成的转换，不要每次都交给模型重新推理；
证据已经足够时停止搜索，不为了显得认真继续调用工具；
只有在评测证明质量提高时，才增加推理强度或多 Agent 并行。

最后要记录的指标，也不应该只有 Token：

任务通过率
平均重试次数
人工接管率
完成耗时
单次通过任务的总成本

资源用得更少，只有在结果仍然通过验收时，才算优化。

五、不要急着做超级 Agent，先让能力能够组合

梁文锋提到，DeepSeek 无意成为下一个超级 App，也不希望与所有大厂和创业公司变成对手。

这首先是一个产品边界的判断：如果基础模型公司亲自进入每一个下游场景，就会与那些基于其模型开发产品的团队形成竞争。对 Agent 开发真正有借鉴意义的，不是“要不要做超级 App”，而是背后的架构选择——当系统不断接入搜索、浏览器、数据库和发布平台时，是否必须把这些能力全部塞进一个 Agent？

未必。产品当然可以有自己的入口，但能力层最好保留清晰的边界，让不同组件可以被调用、替换和复用，而不是由一个 Agent 把所有步骤包成无法拆解的黑盒。

更可持续的方式，是把系统拆成能够组合的部件：

工具负责完成边界清楚的动作；
Skill 保存一类任务的步骤、判断标准和验证方式；
MCP 或稳定 API 提供统一的能力接口；
Agent 根据当前目标选择合适能力；
文件、日志和结构化结果可以被其他系统继续使用。

比如“发布公众号文章”不需要成为某个全能 Agent 的隐藏能力。它可以是一条独立工作流：读取文章、检查元数据、验证配图、渲染预览、上传素材、创建草稿。研究 Agent、写作 Agent 或人工编辑都可以在需要时调用它。

这种可组合性并不以公开全部代码为前提，重点是让系统保留必要的迁移和替换空间：

数据可以导出；
产物可以追溯；
工具可以替换；
模型可以路由；
重复流程可以独立复用。

比起做一个“什么都会”的超级 Agent，先让一项项能力能够可靠组合，通常更接近真实工程。

六、持续学习应该是一条受控改进链，而不是 Agent 自己改自己

在语录里，Agent 之后的重要台阶是持续学习。

这很容易让开发者产生一个冲动：让 Agent 自动读取全部对话、总结经验、修改自己的 Prompt 和 Skill，然后越用越聪明。

但当前系统里的 Memory，通常只是把过去的信息重新放进上下文；它不等于模型真正学会了新能力。未经检查的自动改写，还可能把一次偶然成功、错误反馈甚至恶意内容写成长期规则。

现阶段更可靠的“持续学习”，应该是一条受控的工程闭环：

流程图

这里有几个关键边界：

原始对话不能直接变成长期规则；
用户偏好、业务事实和安全约束要分开保存；
每次改动最好只改变一组相关变量；
新规则必须在正常、边界和失败案例上回归；
生产 Agent 和实验 Agent 使用不同的权限与数据范围；
无法证明有效的经验，不进入公共 Skill。

这条链路看起来没有“Agent 自我进化”那么激动人心，却更接近一个能够长期运行的系统。

语录里还提到一种组织方式：主线工作保持一致，同时给团队保留自主探索空间。Agent 团队也可以采用类似结构——稳定接口、权限和 Eval 作为生产主线；新模型、新工具和多 Agent 方案在隔离环境中实验。验证有效之后，再进入主系统。

不必机械照搬一半时间做主线、一半时间自由研究。值得借鉴的是：稳定和探索需要同时存在，但不能混在同一个生产环境里。

结语：克制不是少做，而是提高做成的概率

梁文锋的这些语录，谈的是一家模型公司的 AGI 路线。Agent 开发团队面对的规模、资源和目标都不同，不应该直接复制它的商业选择或组织方式。

但“克制用来提高做成的概率”这条判断，很适合拿来检查 Agent 项目。

每增加一个模型、工具、记忆模块或子 Agent 之前，可以先问：

它是否直接服务核心交付？
成功以后会留下什么可检查的结果？
失败时系统怎样知道？
它降低了单次有效交付的成本，还是只增加了复杂度？
这项经验经过回归测试了吗？

如果这些问题还答不上来，下一步可能不是继续增加能力，而是把当前主线做得更清楚。

一个成熟的 Agent 系统，当然要知道自己能做什么。

它也应该知道，哪些事情现在不做。

参考资料

elsewhere：《梁文锋四小时投资人会议实录》（52 条语录整理，整理者注明部分词句可能与原话略有出入）
OpenAI：《Prompting guidance for GPT-5.6》
https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6