Chamath 说长时程任务仍是笑话AI 的幻灭低谷开发者该怎么看过去两年AI 圈最不缺的就是“颠覆性进展”。今天 Agent 写代码明天大模型做研究后天仿佛全人类都能被 AI 接管。但就在这种氛围里一个反共识的声音值得注意Chamath 认为长时程任务至今仍然是个笑话AI 正在走向幻灭低谷。这句话扔出来很多人第一反应是“他又在唱衰”。但真正在一线做过 Agent 开发的人可能反而会心一笑。因为大家心里都清楚Demo 里的乖巧 Agent 和真实业务里的自动化流程中间隔着的不是一层窗户纸而是一整座工程大山。长时程任务的可靠性、成本、可观测性和容错能力目前确实没有达到“可用”的标准线。这篇文章不想跟着喊口号也不想无脑反驳。我想从技术角度拆一拆Chamath 的判断依据是什么长时程任务到底难在哪为什么“幻灭低谷”对开发者来说反而是件好事以及在这个阶段我们到底该怎么用 AI 才不亏。1. 先搞清楚他在说“AI 没用”还是“AI 被高估了”要理解 Chamath 的观点得先明确一个边界。他并不是说大模型没有价值也不是说 AI 写文章、做总结、搞代码补全没用。他说的是“长时程任务”long-horizon tasks——也就是那种需要 Agent 自主规划、多步骤执行、跨系统调用、持续数小时甚至数天的复杂任务。这类任务的典型代表包括让 AI 从零开始做一个完整的软件功能包括需求分析、编码、测试、部署、修复缺陷。让 AI 在几十个数据源中做竞品调研产出结构化报告并根据反馈自动迭代。让 AI 像一个真实员工一样处理客服工单、协调多个系统权限、操作多个后台。这些场景的共同点是步骤多、链条长、失败点密集、外部依赖复杂。演示视频里AI 可以顺畅地完成“帮我订一张去北京的机票找好酒店安排三天的行程”。但在真实生产环境中它可能在第 2 步就因权限不足崩溃在第 5 步因 API 返回格式变化而胡言乱语在第 10 步干脆忘记了最初的目标。ChatGPT 之类的工具擅长的是“单次高质量生成”部分 Agent 框架能做到“短链路的自主执行”但距离“长时程任务的稳定自治”确实还有明显差距。所以 Chamath 说的“笑话”不是嘲笑 AI 本身而是嘲笑资本市场和舆论对 AI 能力的过度包装。2. 长时程任务为什么这么难不只是模型问题更是系统工程问题很多非技术人员会以为长时程任务难在“模型不够聪明”。但真实瓶颈往往不在模型智力而在工程实现。拆开看至少有四个层面的难题。2.1 错误累积与偏差漂移一个单步成功率高达 99% 的任务执行 100 步之后整体成功率会跌到约 36%。如果用成本更高的模型和更细的提示词把单步成功率提到 99.5%100 步之后也只有约 60%。这不是玄学而是最基本的概率叠加。实际问题比这更麻烦Agent 每执行一步都会改变上下文状态。如果某一步产生了错误输出后续所有步骤都会构建在错误的基础之上而且这种偏差往往不会自动修正。人类在意识到跑偏时会停下来重新审视目标但当前的 Agent 系统缺少这种“元认知”机制它只会忠诚地把错误放大。2.2 外部系统的不确定性长时程任务几乎不可能在封闭环境里完成。Agent 必须调用 API、操作数据库、读写文件、触发 CI/CD 流水线甚至操作第三方 SaaS 系统。这些外部系统并不会因为调用方是 AI 就变得友好。网络超时、接口鉴权过期、字段格式变化、业务方临时更新了参数、下游服务出现 503——任何一个不可控因素都会中断任务链条。更麻烦的是Agent 往往无法从失败中恢复。它可能重试三次也可能是直接把错误信息写进结果然后假装任务完成了。做 Agent 开发的同行应该都遇到过这种情况打开日志发现 Agent 在凌晨三点反复调用一个已经失效的接口重试了二十次烧掉了大量 token最后产出一份完全错误的结果。这已经是目前长时程任务最典型的失败模式。2.3 上下文窗口的物理限制长时程任务意味着长时间的执行过程也意味着巨量的中间上下文。一个执行了 2 小时的任务可能产生几十万 token 的中间日志、工具返回结果、思考过程。这些信息无法全部塞进上下文窗口必须做截断、摘要或向量化存储。但压缩必然带来信息损失。Agent 在任务后期可能已经忘记了前面某个关键参数的来源只能靠摘要“猜测”。这种压缩导致的失忆在处理需要精细一致性保证的任务时非常危险。2.4 可观测性和恢复能力几乎为零传统的软件系统崩溃了有堆栈、有日志、有指标。Agent 系统要是中途崩了开发者往往只看到一句“抱歉我无法完成这个任务”。既不知道它执行到了哪一步也无法从断点继续更没法复现问题。这种“黑盒失败”是长时程任务落地的最大工程障碍。企业可以容忍一个偶尔出错的 API但无法接受一个执行了 3 小时却无法审计、无法断点续跑、无法定位失败原因的“数字员工”。3. 从“演示惊艳”到“生产可用”中间隔了一整条工程链很多人混淆了“技术能力”和“产品能力”。ChatGPT 的演示视频、Claude 的多步操作、Cursor 的自动改代码展示的都是技术上限。但生产系统要求的是稳定下限而不是偶尔惊艳的上限。举一个很直观的例子让 AI Agent 写一个 Python 脚本它大概率能写得不错。但让这个 Agent 完成“从需求分析到灰度发布一个完整后端服务”需要处理多少工程细节它需要理解需求文档。它需要选择技术栈并创建项目结构。它需要写代码并保证风格统一。它需要写单元测试且测试覆盖率达标。它需要处理依赖冲突。它需要配置 CI/CD 流水线。它需要上线后监控日志并修复问题。这个过程由人类来做也需要一个完整团队的分工协作。开发者经验会体现在每一个环节的判断上什么时候该读文档什么时候该查日志什么时候该停下来和同事沟通。而当前的 Agent 系统只是把“写代码”这一步做得比较出色其余环节还处于“能跑但不可靠”的状态。所以Chamath 说“长时程任务仍是笑话”更准确的理解是目前 Agent 的工程化水平配不上资本市场给它的估值。4. 幻灭低谷不是坏事它挤掉的是泡沫留下的是需求“幻灭低谷”这个词来自 Gartner 技术成熟度曲线。任何一个技术都要经历技术萌芽期、期望膨胀期、幻灭低谷期、稳步爬升恢复期和生产成熟期。AI 在 2023 到 2025 年经历了明显的期望膨胀。那个时候很多人认为“什么都可以交给 AI”创业公司只要在 PPT 上写“AI 驱动”就能拿到融资开发者只要调几个 API 就能做出明星产品。这种过热必然带来反噬——当真实效果达不到预期时资本会冷却舆论会转向企业会收紧预算。但对真正做技术的开发者来说冷却期反而可能是最好的土壤。泡沫期大量资源被平庸的“套壳应用”消耗。低谷期大家才会认真思考哪些场景真的适合 AI哪些只是伪需求。低谷期企业的采购标准从“看起来很酷”变成“能解决实际问题的投入产出比”。低谷期真正有工程能力的团队反而容易跑出来。从技术演进的规律看大模型的基础能力并没有退步多模态、推理、工具调用都在增强。变冷的是商业预期而不是技术路线。这个阶段能活下来的应用往往更务实更愿意做脏活累活更关注与业务系统的集成深度。5. 面对“幻灭低谷”开发者应该怎么办与其焦虑“AI 是不是不行了”不如换一个视角当前技术水位下什么能做什么不能做怎么做才能不踩坑。这里给出几组实际建议。5.1 把“长时程任务”降维成“短链路自动化”不要一上来就追求“让 Agent 独立完成整个项目”。可以先把业务拆分成一个个短链路任务让 AI 在每条链路上做到高可靠。比如把“AI 自动修复线上 Bug”降维成“AI 根据日志和代码上下文生成修复建议由人来确认后合入”。前者是长时程自治后者是短链路辅助。显然后者在今天更接地气也更容易落地。5.2 给 Agent 加状态管理和断点恢复如果一个任务必须跨多个步骤执行开发者就应该把它当分布式系统来设计而不是当“对话”来设计。具体手段包括用工作流引擎管理步骤状态而不是让模型自行记忆。每一步的输入输出都做持久化。任务失败时能定位到具体的失败步骤。支持从失败节点重试而不是从头开始。把 Agent 封装成可恢复的工作流这是在当前模型能力下提高长时程任务成功率的有效路径。5.3 用确定性代码兜底非确定性模型做决策工程上最稳妥的 Agent 架构往往不是“让模型做所有事”而是“让模型做决策让代码做执行”。比如解析日志、写文件、调用 HTTP API 这类确定性的操作应该交给传统代码完成模型只负责理解意图、拆解步骤、选择执行路径。这样即使模型幻觉也不会直接破坏系统状态。5.4 不要忽视成本治理长时程任务必然消耗更多 token。一个执行了 50 步的 Agent 任务可能每轮迭代都要发送几万 token 的上下文。如果业务量再上来成本会很快失控。建议在任务设计阶段就明确 token 预算。比如限制最大步骤数。对中间结果做摘要压缩。对工具返回的大段内容只保留关键字段。低频任务用高精度大模型高频任务用低精度的轻量模型。5.5 重视可观测性建设Agent 的可观测性比传统系统更复杂因为你需要同时追踪“模型在思考什么”和“系统在做什么”。至少应该做到记录完整运行链路包括任务 ID、节点 ID、耗时、成本。记录每一步的模型输入输出。记录工具的调用参数和返回结果。对失败节点做标记和分析。提供慢查询分析和异常检测。只有把 Agent 当作生产系统来监控才能找到失败模式进而逐步逼近“可用”的门槛。6. 现在还适合学 Agent 开发吗答案是可以但请调整目标。如果是为了找一找产品灵感做做原型验证现在依然是很好的时机。工具链在成熟模型能力在提升社区沉淀的工程范式也越来越多。如果要投入到长时程自治 Agent 的研发建议先评估自己的团队是否有能力解决上面提到的工程问题。如果只是调 API 接一个开源框架大概率会在早期就碰到可靠性、成本、可观测性的天花板。当前阶段比较健康的入局方式是选择一个流程相对标准、反馈周期短的垂直场景。先用手工脚本 提示词的方式跑通流程。再逐步引入 Agent 框架管理状态和执行。持续建设评估集用离线评测防止模型升级带来的回归。这种“先窄后宽、先人工后自动”的路径比一上来就想做“通用 AI 员工”要现实得多。7. 常见迷思与真实边界关于长时程任务和 AI 幻灭有四个反复出现的迷思值得单独拎出来说明。迷思真实情况模型越强Agent 就越可靠模型智能只是基础设施可靠性取决于工程架构和容错设计长时程任务只是“多调几次 API”涉及状态管理、错误恢复、可观测性、成本治理等系统工程能力Demo 能跑通生产也能跑通演示环境的成功率不可信生产环境的偶发失败才是常态AI 进入幻灭低谷就等于没戏了低谷期挤掉的是泡沫基础技术仍在爬升真正适合落地的场景会浮现这四条建议收藏在写方案或者给领导汇报的时候直接用得上。8. 给团队和决策者的落地建议如果你正在为团队规划 AI 应用方向下面这几个原则值得参考。第一从单点提效切入不要从“替代人”切入。先找一个高重复、低风险、反馈明确的环节把 AI 接进去让效率提升被真实度量。有了一个成功的样板再扩展边界。第二用预算约束产品形态。任何一个 Agent 功能上线前都要回答单任务平均成本多少毛利能不能覆盖如果用户量增加 10 倍成本是否可控第三建立持续的离线评测机制。没有评测集的 Agent 项目就像没有测试的 Web 应用迟早会在重构中崩塌。建议每个 Agent 场景都维护一组基准任务每次更换模型、修改提示词、升级框架都跑一遍回归测试。第四不要忽视安全与权限。当 Agent 开始操作生产系统时最小权限原则比什么都重要。建议给 Agent 单独创建专用账号严格限制它能访问的资源和能执行的命令并保留完整审计日志。9. 总结低谷期恰恰是动手期回到 Chamath 的判断长时程任务是不是笑话从生产可用性的角度看目前确实还撑不起“自主完成复杂任务”的承诺。但更准确的总结是——长时程任务不是不可能而是需要大量工程工作去逼近“可用”的底线。目前的 Agent 生态像是 2007 年的智能手机方向是对的硬件够用了但操作系统、开发者工具、应用生态都还差一口气。在幻灭低谷期对开发者最有益的策略不是观望也不是狂热而是确定边界做深场景积累工程能力。AI 会像所有颠覆性技术一样在质疑中成熟。对于看得懂技术水位的人来说这个阶段恰恰是锻炼基本功、建立竞争壁垒的窗口期。建议收藏本文等 Agent 真正进入生产成熟期时再回来看你会理解今天这些“保守”判断的含金量。
长时程任务为何难落地？AI幻灭低谷下的Agent工程化思考
Chamath 说长时程任务仍是笑话AI 的幻灭低谷开发者该怎么看过去两年AI 圈最不缺的就是“颠覆性进展”。今天 Agent 写代码明天大模型做研究后天仿佛全人类都能被 AI 接管。但就在这种氛围里一个反共识的声音值得注意Chamath 认为长时程任务至今仍然是个笑话AI 正在走向幻灭低谷。这句话扔出来很多人第一反应是“他又在唱衰”。但真正在一线做过 Agent 开发的人可能反而会心一笑。因为大家心里都清楚Demo 里的乖巧 Agent 和真实业务里的自动化流程中间隔着的不是一层窗户纸而是一整座工程大山。长时程任务的可靠性、成本、可观测性和容错能力目前确实没有达到“可用”的标准线。这篇文章不想跟着喊口号也不想无脑反驳。我想从技术角度拆一拆Chamath 的判断依据是什么长时程任务到底难在哪为什么“幻灭低谷”对开发者来说反而是件好事以及在这个阶段我们到底该怎么用 AI 才不亏。1. 先搞清楚他在说“AI 没用”还是“AI 被高估了”要理解 Chamath 的观点得先明确一个边界。他并不是说大模型没有价值也不是说 AI 写文章、做总结、搞代码补全没用。他说的是“长时程任务”long-horizon tasks——也就是那种需要 Agent 自主规划、多步骤执行、跨系统调用、持续数小时甚至数天的复杂任务。这类任务的典型代表包括让 AI 从零开始做一个完整的软件功能包括需求分析、编码、测试、部署、修复缺陷。让 AI 在几十个数据源中做竞品调研产出结构化报告并根据反馈自动迭代。让 AI 像一个真实员工一样处理客服工单、协调多个系统权限、操作多个后台。这些场景的共同点是步骤多、链条长、失败点密集、外部依赖复杂。演示视频里AI 可以顺畅地完成“帮我订一张去北京的机票找好酒店安排三天的行程”。但在真实生产环境中它可能在第 2 步就因权限不足崩溃在第 5 步因 API 返回格式变化而胡言乱语在第 10 步干脆忘记了最初的目标。ChatGPT 之类的工具擅长的是“单次高质量生成”部分 Agent 框架能做到“短链路的自主执行”但距离“长时程任务的稳定自治”确实还有明显差距。所以 Chamath 说的“笑话”不是嘲笑 AI 本身而是嘲笑资本市场和舆论对 AI 能力的过度包装。2. 长时程任务为什么这么难不只是模型问题更是系统工程问题很多非技术人员会以为长时程任务难在“模型不够聪明”。但真实瓶颈往往不在模型智力而在工程实现。拆开看至少有四个层面的难题。2.1 错误累积与偏差漂移一个单步成功率高达 99% 的任务执行 100 步之后整体成功率会跌到约 36%。如果用成本更高的模型和更细的提示词把单步成功率提到 99.5%100 步之后也只有约 60%。这不是玄学而是最基本的概率叠加。实际问题比这更麻烦Agent 每执行一步都会改变上下文状态。如果某一步产生了错误输出后续所有步骤都会构建在错误的基础之上而且这种偏差往往不会自动修正。人类在意识到跑偏时会停下来重新审视目标但当前的 Agent 系统缺少这种“元认知”机制它只会忠诚地把错误放大。2.2 外部系统的不确定性长时程任务几乎不可能在封闭环境里完成。Agent 必须调用 API、操作数据库、读写文件、触发 CI/CD 流水线甚至操作第三方 SaaS 系统。这些外部系统并不会因为调用方是 AI 就变得友好。网络超时、接口鉴权过期、字段格式变化、业务方临时更新了参数、下游服务出现 503——任何一个不可控因素都会中断任务链条。更麻烦的是Agent 往往无法从失败中恢复。它可能重试三次也可能是直接把错误信息写进结果然后假装任务完成了。做 Agent 开发的同行应该都遇到过这种情况打开日志发现 Agent 在凌晨三点反复调用一个已经失效的接口重试了二十次烧掉了大量 token最后产出一份完全错误的结果。这已经是目前长时程任务最典型的失败模式。2.3 上下文窗口的物理限制长时程任务意味着长时间的执行过程也意味着巨量的中间上下文。一个执行了 2 小时的任务可能产生几十万 token 的中间日志、工具返回结果、思考过程。这些信息无法全部塞进上下文窗口必须做截断、摘要或向量化存储。但压缩必然带来信息损失。Agent 在任务后期可能已经忘记了前面某个关键参数的来源只能靠摘要“猜测”。这种压缩导致的失忆在处理需要精细一致性保证的任务时非常危险。2.4 可观测性和恢复能力几乎为零传统的软件系统崩溃了有堆栈、有日志、有指标。Agent 系统要是中途崩了开发者往往只看到一句“抱歉我无法完成这个任务”。既不知道它执行到了哪一步也无法从断点继续更没法复现问题。这种“黑盒失败”是长时程任务落地的最大工程障碍。企业可以容忍一个偶尔出错的 API但无法接受一个执行了 3 小时却无法审计、无法断点续跑、无法定位失败原因的“数字员工”。3. 从“演示惊艳”到“生产可用”中间隔了一整条工程链很多人混淆了“技术能力”和“产品能力”。ChatGPT 的演示视频、Claude 的多步操作、Cursor 的自动改代码展示的都是技术上限。但生产系统要求的是稳定下限而不是偶尔惊艳的上限。举一个很直观的例子让 AI Agent 写一个 Python 脚本它大概率能写得不错。但让这个 Agent 完成“从需求分析到灰度发布一个完整后端服务”需要处理多少工程细节它需要理解需求文档。它需要选择技术栈并创建项目结构。它需要写代码并保证风格统一。它需要写单元测试且测试覆盖率达标。它需要处理依赖冲突。它需要配置 CI/CD 流水线。它需要上线后监控日志并修复问题。这个过程由人类来做也需要一个完整团队的分工协作。开发者经验会体现在每一个环节的判断上什么时候该读文档什么时候该查日志什么时候该停下来和同事沟通。而当前的 Agent 系统只是把“写代码”这一步做得比较出色其余环节还处于“能跑但不可靠”的状态。所以Chamath 说“长时程任务仍是笑话”更准确的理解是目前 Agent 的工程化水平配不上资本市场给它的估值。4. 幻灭低谷不是坏事它挤掉的是泡沫留下的是需求“幻灭低谷”这个词来自 Gartner 技术成熟度曲线。任何一个技术都要经历技术萌芽期、期望膨胀期、幻灭低谷期、稳步爬升恢复期和生产成熟期。AI 在 2023 到 2025 年经历了明显的期望膨胀。那个时候很多人认为“什么都可以交给 AI”创业公司只要在 PPT 上写“AI 驱动”就能拿到融资开发者只要调几个 API 就能做出明星产品。这种过热必然带来反噬——当真实效果达不到预期时资本会冷却舆论会转向企业会收紧预算。但对真正做技术的开发者来说冷却期反而可能是最好的土壤。泡沫期大量资源被平庸的“套壳应用”消耗。低谷期大家才会认真思考哪些场景真的适合 AI哪些只是伪需求。低谷期企业的采购标准从“看起来很酷”变成“能解决实际问题的投入产出比”。低谷期真正有工程能力的团队反而容易跑出来。从技术演进的规律看大模型的基础能力并没有退步多模态、推理、工具调用都在增强。变冷的是商业预期而不是技术路线。这个阶段能活下来的应用往往更务实更愿意做脏活累活更关注与业务系统的集成深度。5. 面对“幻灭低谷”开发者应该怎么办与其焦虑“AI 是不是不行了”不如换一个视角当前技术水位下什么能做什么不能做怎么做才能不踩坑。这里给出几组实际建议。5.1 把“长时程任务”降维成“短链路自动化”不要一上来就追求“让 Agent 独立完成整个项目”。可以先把业务拆分成一个个短链路任务让 AI 在每条链路上做到高可靠。比如把“AI 自动修复线上 Bug”降维成“AI 根据日志和代码上下文生成修复建议由人来确认后合入”。前者是长时程自治后者是短链路辅助。显然后者在今天更接地气也更容易落地。5.2 给 Agent 加状态管理和断点恢复如果一个任务必须跨多个步骤执行开发者就应该把它当分布式系统来设计而不是当“对话”来设计。具体手段包括用工作流引擎管理步骤状态而不是让模型自行记忆。每一步的输入输出都做持久化。任务失败时能定位到具体的失败步骤。支持从失败节点重试而不是从头开始。把 Agent 封装成可恢复的工作流这是在当前模型能力下提高长时程任务成功率的有效路径。5.3 用确定性代码兜底非确定性模型做决策工程上最稳妥的 Agent 架构往往不是“让模型做所有事”而是“让模型做决策让代码做执行”。比如解析日志、写文件、调用 HTTP API 这类确定性的操作应该交给传统代码完成模型只负责理解意图、拆解步骤、选择执行路径。这样即使模型幻觉也不会直接破坏系统状态。5.4 不要忽视成本治理长时程任务必然消耗更多 token。一个执行了 50 步的 Agent 任务可能每轮迭代都要发送几万 token 的上下文。如果业务量再上来成本会很快失控。建议在任务设计阶段就明确 token 预算。比如限制最大步骤数。对中间结果做摘要压缩。对工具返回的大段内容只保留关键字段。低频任务用高精度大模型高频任务用低精度的轻量模型。5.5 重视可观测性建设Agent 的可观测性比传统系统更复杂因为你需要同时追踪“模型在思考什么”和“系统在做什么”。至少应该做到记录完整运行链路包括任务 ID、节点 ID、耗时、成本。记录每一步的模型输入输出。记录工具的调用参数和返回结果。对失败节点做标记和分析。提供慢查询分析和异常检测。只有把 Agent 当作生产系统来监控才能找到失败模式进而逐步逼近“可用”的门槛。6. 现在还适合学 Agent 开发吗答案是可以但请调整目标。如果是为了找一找产品灵感做做原型验证现在依然是很好的时机。工具链在成熟模型能力在提升社区沉淀的工程范式也越来越多。如果要投入到长时程自治 Agent 的研发建议先评估自己的团队是否有能力解决上面提到的工程问题。如果只是调 API 接一个开源框架大概率会在早期就碰到可靠性、成本、可观测性的天花板。当前阶段比较健康的入局方式是选择一个流程相对标准、反馈周期短的垂直场景。先用手工脚本 提示词的方式跑通流程。再逐步引入 Agent 框架管理状态和执行。持续建设评估集用离线评测防止模型升级带来的回归。这种“先窄后宽、先人工后自动”的路径比一上来就想做“通用 AI 员工”要现实得多。7. 常见迷思与真实边界关于长时程任务和 AI 幻灭有四个反复出现的迷思值得单独拎出来说明。迷思真实情况模型越强Agent 就越可靠模型智能只是基础设施可靠性取决于工程架构和容错设计长时程任务只是“多调几次 API”涉及状态管理、错误恢复、可观测性、成本治理等系统工程能力Demo 能跑通生产也能跑通演示环境的成功率不可信生产环境的偶发失败才是常态AI 进入幻灭低谷就等于没戏了低谷期挤掉的是泡沫基础技术仍在爬升真正适合落地的场景会浮现这四条建议收藏在写方案或者给领导汇报的时候直接用得上。8. 给团队和决策者的落地建议如果你正在为团队规划 AI 应用方向下面这几个原则值得参考。第一从单点提效切入不要从“替代人”切入。先找一个高重复、低风险、反馈明确的环节把 AI 接进去让效率提升被真实度量。有了一个成功的样板再扩展边界。第二用预算约束产品形态。任何一个 Agent 功能上线前都要回答单任务平均成本多少毛利能不能覆盖如果用户量增加 10 倍成本是否可控第三建立持续的离线评测机制。没有评测集的 Agent 项目就像没有测试的 Web 应用迟早会在重构中崩塌。建议每个 Agent 场景都维护一组基准任务每次更换模型、修改提示词、升级框架都跑一遍回归测试。第四不要忽视安全与权限。当 Agent 开始操作生产系统时最小权限原则比什么都重要。建议给 Agent 单独创建专用账号严格限制它能访问的资源和能执行的命令并保留完整审计日志。9. 总结低谷期恰恰是动手期回到 Chamath 的判断长时程任务是不是笑话从生产可用性的角度看目前确实还撑不起“自主完成复杂任务”的承诺。但更准确的总结是——长时程任务不是不可能而是需要大量工程工作去逼近“可用”的底线。目前的 Agent 生态像是 2007 年的智能手机方向是对的硬件够用了但操作系统、开发者工具、应用生态都还差一口气。在幻灭低谷期对开发者最有益的策略不是观望也不是狂热而是确定边界做深场景积累工程能力。AI 会像所有颠覆性技术一样在质疑中成熟。对于看得懂技术水位的人来说这个阶段恰恰是锻炼基本功、建立竞争壁垒的窗口期。建议收藏本文等 Agent 真正进入生产成熟期时再回来看你会理解今天这些“保守”判断的含金量。
