编译 | Tina 过去几十年，软件工程有一个稳定不变的前提：系统的行为写在代码里。工程师读代码，就能推断系 统在大多数场景下会怎么运行；测试、调试、上线，也都围绕"确定性"展开。但 Agent 的出现正在动 摇这个前提：在 Agent 应用里，决定行为的不再只是代码，还有模型本身——一个在代码之外运 行、带着非确定性的黑箱。你无法只靠读代码理解它，只能让它跑起来、看它在真实输入下做了什 么，才知道系统"到底在干什么"。 在播客中，LangChain 创始人 Harrison Chase 还把最近一波"能连续跑起来"的编程 Agent、Deep Research 等现象视为拐点，并判断这类"长任务 Agent"的落地会在 2025 年末到 2026 年进一步加 速。 这也把问题推到了台前：2026 被很多人视为"长任务 Agent 元年"，现有的软件公司还能不能熬过 去？就像当年从 on-prem 走向云，并不是所有软件公司都成功转型一样，工程范式一旦变化，就会 重新筛选参与者。长任务 Agent 更像"数字员工"——它不是多回合聊天那么简单，而是能在更长时间 里持续执行、反复试错、不断自我修正。 在这期与红 ...

转自：InfoQ ，编译 | Tina 过去几十年，软件工程有一个稳定不变的前提：系统的行为写在代码里。工程师读代码，就能推断系 统在大多数场景下会怎么运行；测试、调试、上线，也都围绕"确定性"展开。但 Agent 的出现正在动 摇这个前提：在 Agent 应用里，决定行为的不再只是代码，还有模型本身——一个在代码之外运 行、带着非确定性的黑箱。你无法只靠读代码理解它，只能让它跑起来、看它在真实输入下做了什 么，才知道系统"到底在干什么"。 在播客中，LangChain 创始人 Harrison Chase 还把最近一波"能连续跑起来"的编程 Agent、Deep Research 等现象视为拐点，并判断这类"长任务 Agent"的落地会在 2025 年末到 2026 年进一步加 速。 这也把问题推到了台前：2026 被很多人视为"长任务 Agent 元年"，现有的软件公司还能不能熬过 去？就像当年从 on-prem 走向云，并不是所有软件公司都成功转型一样，工程范式一旦变化，就会 重新筛选参与者。长任务 Agent 更像"数字员工"——它不是多回合聊天那么简单，而是能在更长时间 里持续执行、反复试错、不断自 ...

扣子2.0版本核心更新 - 产品更新至2.0版本，并更换了logo [1] - 本次更新引入了两个被作者认为非常实用且及时的核心功能：Skills（技能）和长期计划 [4] Skills（技能）功能详解 - Skills被视为继2024年Prompt工程、2025年上下文工程之后，2026年可能兴起的“Skills工程” [4] - 此前Skills功能主要集成在如OpenCode、CodeX、Antigravity等编程工具中，对普通用户门槛较高 [4] - 扣子作为一款Agent产品，集成Skills功能顺理成章，大幅降低了普通用户使用和创建Skills的门槛 [4] - 用户可通过在对话框输入“@”键来调用已拥有的技能 [4] - 官方内置了大量开箱即用的技能，涵盖写作、制作PPT、设计、视频处理等领域 [6] - 用户也可以使用他人创建并上架到技能商店的技能 [7] Skills的创建与抽象化价值 - 作者强调，未来个人的核心竞争力在于能否将重复性需求抽象成Skills并集成到主Agent中 [7] - 任何需要重复3次及以上的非沟通类任务，都应该被Skill化 [7] - 扣子平台的核心价值之一是帮助用户以极低成本将个人经验Skill化 [7] - 平台提供了两种创建技能的方式，分别面向普通用户和专业用户 [7] 面向普通用户的“口喷式”Skills开发 - 这是扣子上主流的技能构建方式，用户通过自然语言描述即可创建技能 [8] - 例如，用户可以将著名的开源多媒体处理工具FFmpeg的GitHub链接发给AI，要求其打包成一个用于视频格式转换、分辨率修改等功能的Skill [9][10][13] - 构建过程约需一两分钟，部署后即可在对话中调用 [14][15][19] - 实际测试中，调用该技能将一段视频转换为小于10MB的GIF，耗时仅几十秒，效果符合要求 [21][23] - 用户还可以将多个相关开源项目（如FFmpeg和ImageMagick）合并，创建一个能同时处理视频和图片的复合型Skill [24][25][27] - 此类复合技能可处理复杂连续任务，例如按要求将图片转为指定格式并调整视频分辨率，全程自动化处理仅需约2分钟 [29] - 创建好的技能可以上架到技能商店供所有用户使用 [30][32] 面向专业用户的Skills迁移 - 对于已通过Claude Code或OpenCode等工具创建了大量Skills的专业用户，扣子支持直接上传技能文件包（.zip或.skill格式）进行迁移 [33] - 系统会自动识别并创建技能，实现从其他平台到扣子的无缝平移 [33][37] - 目前部分迁移技能的运行成功率尚有优化空间 [38] Skills功能的当前局限与展望 - 目前扣子2.0上的技能只能单独使用，尚不支持多个Skill之间的互相结合与调用，这在一定程度上限制了其能力 [40] - 该更新对于降低Skills使用门槛、推动其普及具有重要作用 [39] - 补齐技能联动等关键短板后，AI助手的能力将得到质的飞跃 [58][60] 长期计划功能详解 - 长期计划功能允许用户为AI设定一个长期目标，AI会将其分解为可执行的步骤，用户只需按计划执行 [42][43] - 例如，用户可以创建一个“2026年全年健康执行路径规划”，AI会先了解用户当前身体状况，然后生成详细的阶段性规划书 [50][54] - 规划书内容系统，包含整体目标、阶段划分、关键里程碑和量化追踪指标体系等 [54] - AI会自动将计划任务添加到日程中，并在设定时间通过网页端弹窗提醒用户 [55] - 在计划执行过程中，用户可以通过与AI对话来不断调整和优化计划 [55] 长期计划功能的当前局限 - 目前计划提醒仅支持网页端，扣子的APP端尚未支持该功能的通知 [55] - 在移动端使用长期计划被认为是刚需，预计APP端支持会很快更新 [57]

Manus公司的市场表现与成功逻辑 - Manus公司开发的AI代理产品自2025年3月正式发布，仅用八个月时间就实现了约1亿美元的年经常性收入，并积累了数百万用户 [3] - 该公司的AI代理能够自动完成从市场调研、数据分析到编码等复杂任务，超越了简单的对话式应答 [3] - 其成功的核心秘诀被归结为“上下文工程”，即利用持久化的Markdown文件作为工作记忆载体，以克服实时上下文窗口容量有限的问题 [9] 开源项目planning-with-files的兴起与功能 - 在Manus产品取得成功后，技术圈出现了名为“planning-with-files”的开源项目，该项目复刻了Manus的核心工作流 [5] - 该项目上线仅几天就在GitHub上获得了超过7.5k的星标，显示出极高的关注度 [5][6] - 该开源项目是一款Claude Code插件，旨在通过持久化的Markdown文件来重构工作流，实现任务规划、进度追踪与知识存储 [7] 现有AI智能体工具的痛点与解决方案 - Claude Code等大多数AI智能体普遍存在记忆易失、目标偏移、隐性错误和上下文过载等问题 [10][11] - 具体问题包括：上下文重置后待办事项丢失；工具调用次数超过50次后原始任务目标易被遗忘；失败操作未被记录导致错误重复；所有信息堆砌在上下文窗口而非持久化存储 [11] - planning-with-files插件通过创建三个核心文件来解决这些问题：`task_plan.md`用于任务规划，`findings.md`用于记录研究发现，`progress.md`用于记录进度日志 [10][14] planning-with-files插件的核心设计理念与规则 - 该插件的核心设计理念是将上下文窗口类比为易失且容量有限的计算机内存，而将文件系统类比为持久且容量无限的计算机硬盘，强调信息务必写入硬盘 [14] - 插件引入了“2-Action规则”：AI每进行两次查看或搜索操作后，必须更新一次`findings.md`，以确保研究成果被即时固化 [14] - 插件引入了“错误日志协议”：所有的报错和失败尝试必须记录在案，AI在尝试新方案前必须先阅读错误日志，严禁重复已失败的路径 [14] - 插件集成了自动化钩子函数，包括SessionStart、PreToolUse、PostToolUse和Stop，以实现流程自动化，例如在执行关键决策前重新读取任务计划，在完成文件写入后提醒更新状态 [14][20] - 插件具备强制校验功能：在AI试图结束任务前，会检查`task_plan.md`中的所有阶段是否都标记为完成 [14] planning-with-files插件的安装与使用 - 插件推荐通过Claude Code命令行工具安装，以支持自动更新和钩子函数的无缝集成 [18] - 系统要求建议使用Claude Code v2.1.0及以上版本来支持钩子函数的全部功能 [21] - 安装成功后，在启动新的Claude Code会话时会出现提示，表明插件已就绪，可自动为复杂任务激活，或通过手动输入指令`/planning-with-files`调用 [23]

文章核心观点 - 上下文工程的优化是AI Agent创业公司当前竞争的重点，其核心思路正从“如何把更多信息塞进上下文”转变为“如何为Agent创建一个信息丰富、易于探索的外部环境”[2][65] - 通过借鉴Cursor和Manus两家头部公司的实践，做好上下文工程的关键在于：实施有效的上下文缩减策略、构建灵活的工具行动空间、以及设计高效的多Agent协作模式[6][65] 上下文缩减策略 - **问题根源：上下文腐烂** Agent每调用一次工具，结果就会被追加到聊天记录中，导致上下文无限制增长[9] 典型任务可能需要调用50次工具，生产环境中的Agent对话轮次可能长达数百轮[10] 这会导致推理性能断崖式下跌，表现为推理变慢、质量下降和无意义重复，即“上下文腐烂”[10] - **主流解决方案：上下文卸载** 业内共识是将信息转移到上下文窗口之外，需要时再精确检索回来，即“上下文卸载”[10] 将信息转移到文件系统是目前生产级Agent中主流且最有效的做法[11] - **Cursor的“动态上下文发现”模式** 其核心是让模型在需要时自己去找信息，而非急于将信息塞给模型[13] 具体做法包括： - 将冗长的工具结果（如巨大的JSON响应或Shell命令输出）直接写入文件，在上下文中仅告知Agent结果的文件位置[14] - 当上下文窗口被填满时，触发“总结”步骤，为Agent提供一份摘要和一个指向完整历史记录文件的引用，Agent可按需搜索该文件获取细节[15] - 将集成终端的所有会话输出同步到本地文件系统，使Agent能直接定位和搜索相关问题[18] - **Manus的结构化可逆缩减系统** 该系统设定明确的触发机制并分阶段执行[19] - **监控与触发**：系统持续监控上下文长度，并设定一个远低于模型硬件极限的“腐烂前阈值”作为触发条件，该阈值通常在12.8万到20万个Token之间[20][21] - **第一阶段：紧凑化** 这是一种无损、可逆的缩减，剥离能从外部状态（如文件系统）重建的信息[22] 例如，将文件写入操作中的冗长`content`字段剥离，仅保留`path`字段[22] 信息被“外部化”而非丢失，Agent后续可通过`path`检索[23] 通常只对最早的50%历史记录进行紧凑化，以保留最新的完整工具调用作为学习范例[24] - **第二阶段：摘要化** 当紧凑化收益微乎其微时启动，这是一种有损但带保险的压缩[25] 保险措施在于：在生成摘要前，将完整的上下文转储到一个文本或日志文件中创建快照存档[26] 摘要化会使用完整版本的数据，并保留最后几次完整的工具调用记录，以保持工作连贯性[28][29] 工具行动空间管理 - **问题根源：工具过载** 将所有工具的冗长描述都放入上下文会导致“上下文混淆”和直接的Token浪费[31][36] - **核心思路：动态发现** 让Agent自己去找要调用哪些工具[31] - **Cursor的策略：工具说明书文件化** 将所有MCP工具和Agent Skills的详细定义同步到文件夹中，Agent在需要时自行查阅[32] 其框架分为索引层和发现层：系统提示词中仅包含工具名称列表，详细描述则存放在本地文件夹供Agent主动搜索[34] 该策略在一次A/B测试中，对于调用了MCP工具的任务，将Token总消耗降低了46.9%[35] 这种方式还能向Agent传达工具状态，例如在MCP服务器需要重新认证时，Agent可以主动告知用户[37][38] - **Manus的策略：分层行动空间** 将Agent能力划分为三个层次[41] - **第一层：原子函数调用** 核心层，只包含极少数固定的、正交的原子函数，如读写文件、执行shell命令、搜索等，此层固定，对KV缓存友好且功能边界清晰[42] - **第二层：沙盒工具** 卸载层，将绝大多数工具（如格式转换器、语音识别工具、MCP调用本身）作为预装软件放在定制的Linux虚拟机沙箱中[43] Agent不在上下文中“看到”这些工具定义，而是通过第一层的shell命令动态交互，例如用`ls /bin`查看可用工具[43] - **第三层：软件包与API** 代码层，对于需要大量内存计算或与复杂第三方服务交互的任务，允许Agent编写并执行Python脚本，仅返回摘要结果[44] 例如，Manus预装了大量API密钥，Agent可用其访问金融API获取市场数据[44] - **设计优势** 从模型角度看，无论使用第二层还是第三层的复杂工具，最终都通过第一层的几个原子函数执行，这种接口设计对模型极度简洁且缓存稳定[47] 多Agent协作模式 - **核心问题：上下文隔离与信息同步** 如何利用多Agent实现“上下文隔离”，让每个子Agent有独立的上下文窗口以实现关注点分离，同时解决它们之间的信息同步难题[49][50] - **两种协作模式** - **任务委托模式（通过通信实现隔离）** 经典的主-子Agent设置，主Agent将任务封装成简短指令发送给子Agent，子Agent上下文完全独立[53] 适用于“过程不重要，只关心结果”的任务，如委托子Agent在代码库中搜索特定代码片段[54] Manus内部称此模式为“Agent即工具”[54] - **信息同步模式（通过共享上下文实现协作）** 子Agent创建时能看到主Agent完整的先前上下文，但拥有独立的系统提示词和行动空间[55] 更适用于高度依赖历史信息、需要综合分析的任务，如深度研究报告[55] 但此模式成本昂贵，因为每个子Agent启动时都需要Prefill大量输入且无法复用主Agent的KV缓存[55] - **通信难点与解决方案：结构化输出** 多Agent通信的难点在于如何从多个并行子Agent处获得结构一致、内容准确的输出[57] Manus设计了一套“Agent化的MapReduce”系统，其关键包括： - **共享沙箱**：主Agent与子Agent共享同一个虚拟机沙箱和文件系统，信息传递可通过文件路径完成[58] - **输出模式**：主Agent在创建子Agent前必须先定义一个输出的Schema，作为强制执行的API合同[59] - **约束解码**：使用约束解码技术，强制子Agent通过专用工具`submit_result`提交的结果必须严格符合主Agent定义的Schema[60] - **核心思路** 无论是做摘要还是Agent间通信，都反复使用模式和结构化输出作为一种“契约”，以保证信息以结构化、完整的方式传递[61] 设计哲学总结 - **Cursor的设计哲学** 强调“少即是多”，认为最初提供给模型的细节越少，效果反而越好，这能让Agent更轻松地自行抓取相关上下文[62] - **Manus的设计哲学** 强调“少构建，多理解”，避免上下文的过度工程化[63] 其经验表明，最大的飞跃来自简化架构、移除不必要的技巧以及对模型多一点的信任，每次简化都使系统更快、更稳定、更智能[63][64] 上下文工程的目标是让模型的工作变得更简单，而不是更难[64]

文章核心观点 - 文章深度剖析了AI初创公司Kuse的产品理念、市场定位、增长策略及其在非结构化数据结构化处理领域的独特价值[1][2][3] - 公司通过聚焦“上下文优先”和“格式化引擎AI”，将产品从通用AI工具转型为面向知识工作者的资产沉淀系统，在未融资情况下3个月内实现近1000万美金年度经常性收入[1][17] - 其增长模式避开了主流社交平台，通过Meta旗下的Threads和Instagram渠道，以极低的运营成本（仅一位实习生负责）成功开拓了台湾和香港市场[18] 产品定位与核心理念 - 产品定位从通用AI工具转为AI原生的“Context First”文件管理与资产沉淀系统[4] - 核心理念是“上下文优先”，围绕文件夹与素材源构建知识库，将用户输入沉淀为可复用的上下文资产[3] - 强调“Chaos in, Genius out”，致力于将复杂杂乱的输入转化为清晰、可消费的网页与文档成果[6] - 与Notion的乐高式模块类似，但基于AI构建，是AI原生结构化的，能自动处理与复用上下文，被形容为“用NotebookLM的方法重做Notion”[8] 产品功能与差异化 - 产品首页不是对话框，而是需要用户先上传文件或提交信息源，走资产沉淀路径，与NotebookLM类似但侧重于企业场景[1][2] - 主打知识库+Webpage交互模式，专注文档和网页生成而非应用开发，目的是为了更好的消费和传递信息[6] - 核心功能是“格式化引擎AI”，除了生成内容，还能自动处理人们消费内容所需的格式排版，如生成格式规范统一的试卷、法律文件、简历等[7][8] - 与大多数AI工具的“一次性生成”模式不同，Kuse构建的是“长期资产”系统，用户上传的信息源成为首个资产，后续生成的新内容会再次成为新资产，支持持续迭代、复用与协作，形成“越用越懂你”的记忆系统和Context复利能力[8][15] 市场需求与产品市场契合 - 解决了非结构化数据结构化的爆发性需求，AI极大提高了对非结构化数据的处理能力，而人们消费信息时需要结构化（包含格式排版）[10] - 产品转型源于用户行为的启示：用户上传PDF、研究论文、课堂笔记的频率远高于使用设计功能，真实痛点是“理解信息”而非设计工具[12][13] - 找到了明确的产品市场契合点，用户群体从设计师扩展到咨询顾问、教育工作者、法律专业人士、产品经理等各类知识工作者[16] - 精准击中了咨询、教育和法律等领域专业人士创建高精度、模板驱动文档（保持完全一致格式）的深层痛点，这是目前大多数AI产品做不到的[16][17] 增长策略与市场表现 - 增长策略独特，几乎全部来自Meta旗下的Threads和Instagram渠道，目前各占一半左右，仅由一位大三实习生负责运营[18] - 选择Threads的原因包括：平台处于快速增长期（尤其在台湾和香港）、竞争较少对新账号友好、没有广告平台使竞争对手无法用资金获得优势[18] - 推广方式简单有效：创建数百个账号，每天发布实用案例（如Markdown转排版、试卷生成），并使用繁体中文针对台湾和香港市场[18] - 公司在未融资的情况下，3个月做到了近1000万美金的年度经常性收入[1][17] 团队与未来方向 - 公司全职团队不到20人，成员来自Meta、Nvidia、Google、字节跳动和Grab等知名公司[22] - 联合创始人兼CEO吴显昆为设计师出身，曾是rct.ai的联合创始人[12][22] - 未来方向聚焦于高频需求，专注用网页或图片生成重格式的文本、文件或Web page，满足排版、文档和网页生成等朴实需求，不关注后端开发和应用制作[22] - 文章认为其底层逻辑与NotebookLM类似但更侧重商业信息分发，未来有机会发展成AI时代的CRM+ERP系统[11]

文章核心观点 - Meta以数十亿美元全资收购AI初创公司Manus，这是Meta历史上第三大规模的并购案[7] - Manus是一家诞生于中国、最终迁往新加坡的AI公司，其故事是中国顶尖技术人才在全球地缘政治与商业现实夹缝中生存、抉择与取得成功的现代寓言[7] - 收购事件凸显了在算力封锁、资本脱钩和技术范式转移的背景下，中国顶尖技术力量面临的挑战与无奈[7][22] 公司背景与团队 - Manus核心团队并非典型学院派，其显著标签是极致的工程能力和对流量与人性的洞察[8] - 创始人肖弘曾创立夜莺科技，开发“壹伴”和“微伴”等微信公众号插件，深谙在巨头生态中做“外挂”的商业逻辑[8] - 首席科学家季逸超是技术灵魂人物，高中时期便因独立开发猛犸浏览器而闻名[11] - 季逸超早期自研NLP模型被GPT-3“降维打击”的经历，促使其确立了“正交性”技术哲学，即不拼底层模型，而是专注于更好地使用模型[11][12] 技术路线与产品创新 - Manus的技术路线是上下文工程，专注于如何更好地使用大模型，而非训练大模型本身[12] - 公司产品定位是AI Agent（智能体），而非Chatbot（聊天机器人），核心是解决实际生产力问题[14] - 在GAIA基准测试中，Manus的得分碾压了OpenAI的Deep Research[16] - Manus的AI Agent能像人类员工一样执行复杂任务，例如进行市场调研、阅读PDF、处理数据并生成PPT[16] - 技术创新体现在构建了一套“虚拟操作系统”，包括虚拟文件系统解决长上下文记忆问题，以及确定性状态机防止AI产生幻觉[16] - 这被视作一场工程学的胜利，证明了在Scaling Law之外，应用层的极致优化和创新同样价值连城[16] 地缘政治与商业抉择 - 2025年7月，Manus母公司“蝴蝶效应”决定将全球总部从北京迁往新加坡，并对中国团队进行大规模裁员[18] - 搬迁决策源于一个“不可能三角”：算力（依赖英伟达H100/H200集群，受美国出口管制限制）、资本（依赖美元基金，受美国AI投资禁令限制）、生态（底层依赖Claude和GPT的API，有断供风险）[19] - 为了生存，公司必须完成“去中国化”，变成一家新加坡公司，以获取美国资本、芯片并服务全球市场[19] - 约40名核心技术骨干迁至新加坡，剩余120多名普通员工在获得N+3甚至2N补偿后解散[19] - 这形成了“中国的大脑 + 新加坡的壳子 + 美国的资本 + 全球的市场”这一未来中国硬科技创业者的潜在范本[19] 行业影响与竞争格局 - AI行业风向从Chatbot转向能实际干活的Agent[14] - Meta收购Manus旨在补齐其应用层短板，Meta拥有强大的开源Llama模型，但缺乏杀手级应用产品[20] - 收购后，Manus的Agent能力可能与Meta的通信产品（如WhatsApp）整合，实现从聊天到处理实际工作的商业模式闭环[21][23] - 对于中国AI产业，Manus的成功证明了其工程师具备定义下一代AI产品的创新能力，实现了“Original from China”[22] - 但中国本土在算力短缺、资本环境及市场隔离方面的挑战，导致此类创新无法滋养本土生态，顶尖人才和公司被迫外流[22]

AI Coding生态演进：从补全到Agent主导 - AI Coding的演进分为两个时代：第一波由Copilot与Cursor开创，以人为主导，AI角色是预测“下一个字符”或“下一个编辑位置”，端到端时延被严格压在几百毫秒量级，模型规模和上下文长度受天然约束 [2] - 第二波在过去6–12个月迎来范式颠覆：Agent崛起，直接接管从需求分析到代码生成、工具调用到结果验证的任务 [2] - 随着模型能力与工具链完善，Agent会覆盖从需求到交付的更多环节，逐渐成为主流程；补全范式可能退居幕后，成为支撑Agent精细执行的底层能力之一 [3] 工具形态演化：IDE、CLI与Cloud并行 - 头部编程工具演化出三种形态并行：IDE、CLI、Cloud，用户需要的是在不同场景下都能交付任务的完整链路 [4] - CLI和Cloud Agent从一开始就是Agent主导形态，对UI要求不高，在Terminal或简化Web界面工作，用GitHub PR协作和交付 [4] - IDE依然被判断为最多人使用的入口，最符合程序员长期形成的工作习惯，但其形态本身很可能在三年内发生根本变化，不再以Editor为中心展开 [4][5] - IDE正在从“给人用的工具箱”变成“给AI和人一起共用的工具箱”，大量以人为中心设计的能力被拆解为更小、更明确、更AI友好化的Tool，供AI Agent按需调用 [5] Spec驱动开发的兴起与挑战 - Spec驱动开发在过去几个月迅速流行，仓库中堆起面向Agent的“Markdown脚手架”，被视为AI Coding的前沿解法 [1] - 行业对“Spec”的定义存在分歧：有人认为是更好的Prompt、更详细的产品需求文档、架构设计文档，或是“在写代码的时候，多用几个Markdown文件” [8] - 一线工具团队认为Spec与上下文工程（Context Engineering）不是一回事：Spec是上下文中最关键、最稳定的一类内容，承担“指导性Context”的角色，相当于给Agent一份可执行的契约；而上下文工程关注模型在当下是否拿到了足够的信息 [9] - Spec是一切用于指导代码生成的契约总和，可包括产品文档、设计稿、接口定义、边界条件、验收标准、执行计划等，但因其覆盖范围广、形态多、生命周期长而难以标准化 [9][10] - Spec标准是否有效取决于应用场景，因为它本质上是用一种文档/结构去交换正确性、效率、维护成本三样东西，不同场景对这三者的权重不同 [12] Spec与软件工程复杂性的对接 - Spec试图接住软件工程几十年积累下来的复杂性，其标准本质上是软件工程理论在AI编程工具中的具象化 [10] - 争议在于Spec驱动开发是否会导致“瀑布流程回归”，即在编码前完成大量文档工作，试图将开发人员从过程中剔除 [13] - 从工程视角看，Spec Coding真正想结构化的并非开发者的全部思考过程，而是那些最容易在长程任务里出错、最值得被验证和沉淀的部分 [13] - Spec更合理的形态是“活的契约”，是Plan-Execute闭环中的关键中间态，在推理-执行-反馈过程中不断校准Spec和代码制品的一致性 [14] - 从软件抽象发展历史看，Spec被视为在自然语言层级上尝试迈出的下一次抽象升级，但自然语言的模糊性决定了这是一条充满挑战、尚无成熟范式的探索路径 [15] Agent的“自己造轮子”问题与抽象复用 - Coding Agent在实践中存在一个被大量开发者吐槽的问题：极其偏好“自己从零开始实现功能”，而不是复用成熟库 [16] - 对模型而言，“自己写一个能跑的版本”往往是风险最低的路径，当它对某个库的版本、用法或边界不确定时，回退到“自己实现”几乎是必然选择 [17] - 解决此问题的关键不在于对Agent进行人工纠偏，而在于补齐其可依赖的信息源，例如通过MCP工具补齐版本、用法与示例，再用“渐进式披露”把正确用法注入任务上下文 [17] Token成本失控与上下文管理成为核心 - Token成本在2025年突然复杂了一个数量级，根本原因在于范式迁移：大模型应用从“问答”跃迁到“Agent做事”，Token成本成为贯穿推理—执行—反馈链路的全生命周期成本 [18][19] - 关键变化是工具调用的隐形成本开始吃掉大头，为了完成一个任务往往需要多轮对话，每轮对话背后又会经历几次到几百次不等的工具调用 [20] - Spec Coding和多Agent协作让成本结构继续膨胀：Spec/Plan/ToDo/变更说明/验收清单等中间产物被反复生成、引用与迭代，形成新的上下文常驻内容；多Agent又把Token变成通信效率问题 [21] - Token工程的真正战场是上下文管理，目标是最大化KV cache命中率，避免在长程Agent任务中被重复、无意义的上下文刷新拖垮吞吐和稳定性 [22] - 上下文工程的技术演进从早期的Prompt Engineering，逐步演进到更系统化的Context Engineering，实践表明以RAG为代表的“外挂式知识补充”在工程上更具性价比 [23] 上下文工程的技术演进路径 - 随着Coding Agent出现，交互从单轮对话转向多轮、长期的Agent Loop，相关信息由Agent在执行过程中按需检索与召回，这催生了embedding search与grep等能力的逐步登场 [24] - Cline和Claude Code在今年就从传统的RAG转向grep [24] - embedding search并未过时，它更像是数据库中的index，在特定条件下能提升召回效率，而grep在确定性和精确匹配上具备优势，两者服务于不同的检索阶段和需求类型 [24] - 随着任务复杂度增加，Agentic Search逐渐演化出来，并与Sub Agent机制协同出现，例如专门的Search Agent负责多轮检索、筛选与验证 [25] - 行业逐渐意识到真正稀缺的不是上下文长度，而是有效Context的组织能力，需通过缓存、裁剪、摘要、检索等机制把Token的边际成本控制在工程可接受的范围内 [25][26] AI编程的系统工程视角 - AI编程被视为一个至少由四层构成的系统工程：模型层负责“思考”，Tool层负责“行动”，IDE层承载人机交互，上下文层负责“记忆与连续性” [27] - 模型层决定上限；Tool层决定它能不能真的做事；IDE层决定人是否能高效表达意图、及时纠偏；上下文层把这一切粘合在一起，承载历史决策、工程约束与连续性，是长期可靠性的基础 [27] - 未来AI编程的真正分水岭，或许并不仅仅在于“谁的模型更强”，而还在于谁能持续、准确地把工程世界中那些原本隐性的约束、记忆和共识，转化为模型可理解、可执行、并可被反复验证的上下文结构 [27]

2025年大语言模型（LLM）发展的核心观点 - 2025年是大语言模型快速演进、重磅事件密集出现的一年，行业格局发生了真正的改变[2][6] - 大语言模型正在显现出一种全新的智能形态，其既比预期的聪明得多，又比预期的愚蠢得多[37] - 大语言模型已经极其有用，但行业甚至还没有发挥出它们10%的潜力[38] 可验证奖励强化学习（RLVR）成为新标配 - 2025年初，几乎所有实验室的LLM生产训练流程都包含预训练、监督微调（SFT）和基于人类反馈的强化学习（RLHF）[8][9] - 2025年，一种新的训练阶段——可验证奖励强化学习（RLVR）——浮出水面并迅速成为事实上的标配[10] - RLVR的核心是让模型在可自动验证的环境中接受强化学习训练，模型能自发学会类似“推理”的策略，如将复杂问题拆解成中间步骤并逐步逼近答案[10] - 与SFT或RLHF这类“计算量相对较小的薄层微调”不同，RLVR使用客观、难以被投机取巧的奖励函数，使得训练可以持续非常久[10] - RLVR提供了极高的能力/成本比，大量吞噬了原本准备用于预训练的算力[10] - 2025年的大部分能力提升，并非来自模型规模的暴涨，而是来自相似规模模型加上更长时间的强化学习训练[11] - RLVR带来了新的“旋钮”：通过在推理时生成更长的思考链条、投入更多测试时算力，模型能力可以继续提升，并呈现出新的扩展定律[11] - OpenAI的o1是第一个明确展示RLVR思路的模型，而2025年初的o3则是让人直观感受到质变拐点的版本[12] 对LLM智能“锯齿状”分布的新认知 - 2025年，行业第一次真正直觉性地理解了LLM智能的“形状”，认识到其与人类智能的优化目标完全不同[14] - 大语言模型的智能被描述为“锯齿状”明显的能力分布：它们可以在某些可验证领域表现得像博学的天才，同时在另一些地方像困惑的小学生，甚至容易被攻击[14] - 这种“锯齿状”智能也解释了为何在2025年对基准测试普遍不当回事与不信任，因为基准测试本质上是可验证环境，天然容易被RLVR或“合成数据训练”所攻破[15] - 模型团队往往会在基准所在的嵌入空间附近“培育能力突起”，把能力尖刺精准地长到测试点上，“在测试集上训练”已经演变成了一门艺术[15] Cursor揭示LLM应用新范式 - Cursor在2025年的爆发清晰地揭示了一种全新的LLM应用层[16] - 像Cursor这样的LLM应用，本质是在为特定垂直领域打包和编排LLM能力，引发了关于“这一层会有多厚”的大量讨论[17] - 基础模型会趋向于“一个通用能力很强的大学毕业生”，而真正把他们组织成专业团队、在具体行业中落地的会是应用层，通过私有数据、传感器、执行器和反馈回路将模型组织并投入实际工作流程[17] - 应用层的关键功能包括：上下文工程、在后台编排多次LLM调用形成复杂的有向无环图、提供面向人的领域专用图形用户界面、提供“自主性滑块”[18] Claude Code定义本地化智能体新形态 - Claude Code被认为是第一个“真正的LLM智能体”，它以循环方式将推理与工具调用串联起来，能持续解决长任务[19] - 更重要的是，它运行在用户的本地电脑上，直接使用用户的环境、数据和上下文[20] - 在一个能力锯齿、起飞缓慢的世界里，更合理的顺序是先让智能体成为开发者身边的伙伴，Claude Code用一个极其优雅、极简、极具说服力的命令行界面形态呈现了这一点[20][21] - 这代表AI不再只是一个访问的网站，而是一个住在电脑里的伙伴，是一次全新的交互范式转变[22][23] “氛围编程”重塑软件开发 - 2025年，AI跨过了关键门槛，使得人们可以只用英语构建复杂程序，甚至忘记代码本身的存在，这被称为“氛围编程”[24][25] - “氛围编程”让编程不再只是专业工程师的专利，同时也让专业工程师可以写出大量原本永远不会被写出来的软件[27] - 代码变得不值钱、短暂存在、并可随意改写与丢弃，这正在重塑软件形态和工作角色[28][29] Nano Banana预示LLM的图形用户界面未来 - Google Gemini的“Nano Banana”是2025年最令人震撼的模型之一，它被视为构建真正LLM图形用户界面的一个早期但重要的信号[31][33] - 其意义不只在于图像生成，而在于文本、图像与世界知识在同一模型中深度纠缠[34] - 在UI/UX层面，“聊天”就像80年代的命令行，而人们更喜欢视觉化、空间化的信息，因此LLM应该用人类偏好的形式（如图片、信息图、幻灯片）进行交流[32][33]

公司财务与增长里程碑 - 公司ARR已突破1亿美元，成为从零到一亿美元ARR最快的初创公司[1] - 公司总收入年化运行率超过1.25亿美元，该数据包含基于使用量的收入和其他业务收入[1] - 自公司1.5版本发布以来，月度复合增长率超过20%[1] - 公司在8月份宣布年化收入突破9000万美元[1] 产品能力与技术演进 - 1.5版本任务完成速度提升近4倍，并能构建完整的Web应用[1] - 产品可在单一上下文中执行整个价值链：研究产出深度内容、构建网站、分析用户交互数据、并基于发现生成见解或演示幻灯片[1] - 近期更新版本已支持移动开发，用户可通过其开发完整的移动App，包括后端和数据库设计[1][2] - 自上线首个通用Agent以来，已累计处理超过147万亿Tokens，创建超过8000万个虚拟计算机实例[3] 用户生态与应用案例 - 有用户通过公司产品开发了完整的移动App，例如构建一个AI笔记产品，并集成OpenAI API，产品还提供了发布到App Store的指南[2] - 在社交媒体上发现有不少日本用户分享使用公司产品制作移动App和Web产品的帖子，推测日本用户占相当比例[2] 通用AI Agent的上下文工程经验 - 核心观点是代理的未来在于巧妙地塑造上下文，通过设计记忆、环境和反馈循环，即使底层模型不变，代理表现也能有质的飞跃[8] - 优先考虑KV缓存：保持前缀稳定，避免在系统提示词开头放置动态信息，并通过只增不删确保上下文序列化是确定性的[5] - 采用遮蔽而非移除工具：当工具数量爆炸时，动态删除工具会导致模型困惑和缓存失效[6] - 将文件系统作为外部记忆：使用持久化存储应对长上下文昂贵和导致性能下降的问题，让模型学会读写文件，将其视为无限大的结构化外部记忆，并实施可恢复压缩[7] - 通过“复述”引导注意力：在上下文中不断更新todo.md文件，通过自然语言将全局目标反复推送到模型的近期注意力范围内，防止代理在长任务中偏离目标[7] - 保留错误的记录：将错误的行动、观察结果和堆栈跟踪保留在上下文中，让模型意识到之前的路径行不通，从而实现错误恢复和自我修正[7]