观点索引

「某个功能属于哪一层」本身可能就是错误的提问方式。审批、计费、超时、事件流都只是功能名称，一个功能通常同时包含多条性质完全不同的保证。

我目前的判据是：不要先问一个功能属于哪一层，而要先把它拆成一条条保证，再看每条保证成立所需的最小事实源作用域。

三层分别对应三种问题——Harness 关心模型怎样行动，控制层关心多个执行者怎样共同完成任务，治理层关心系统之外的人为什么可以相信这些行为。

幂等记录不可能只存在某个 Worker 的内存里。它必须在当前 Worker 崩溃后仍然存在、能被其他 Worker 读取、并在多个 Worker 同时操作时原子裁决，因此必然属于跨执行者共享的事实源。

治理层的边界不是「是否跨组织」。调用 Stripe 时用 Idempotency-Key 虽然跨了两家公司，本质上仍是双方约定的 API 契约；只有当某项事实需要被信任域外的第三方验证时，它才真正进入治理层。

有分数，不等于有结论。用相同代码、相同问题重跑，结果本身就会波动——搜索结果会变、网页有时抓不到、模型对相关性的判断也不稳定。评测不是简单判断通过或失败，还要先理解自己的噪声有多大。

评测不只会否定模型，也会否定你自己的方案。把证据数量扩大一倍后，事实覆盖没提升，数字准确性反而下降——更多证据不等于更多有效信息，不同报告期和口径混在一起反而制造了错误。

评测器本身也会犯错，而且越符合预期的评测结果越容易未经检查就被相信。规则评测器曾把年份当金额、把分部营收和总营收比较；小盘股「质量更差」这个符合直觉的结论，复核后发现差异几乎全来自评测器没见过的表达方式。

真正有价值的是定位错误发生在哪一层。报告把旧新闻的历史营收写成最新数据，正确年报其实就在证据池里——这不是检索失败，而是取信失败。越早发生的信息损坏，越不应该依赖下游模型把它猜回来。

评测驱动并不是「每次提交都要涨分」，而是「每次提交都尽量有可以被证伪的理由」。要把评测看成一组仪表，而不是一个排行榜——压缩成单一总分，就很容易为了优化分数而优化分数。

Run API 的设计哲学是「请求归请求，执行归执行」。API 的作用不是把任务跑完，而是建立契约：校验后在数据库登记一张工单，毫秒级返回 run_id，把控制权交还前端。同步等待在真实业务中完全不可行。

幂等设计是「网络抖动导致重复退款」的唯一解法。对 org_id 和 idempotency_key 建唯一联合约束，相同键加相同 Input 直接返回原 run_id，相同键但不同 Input 返回 409。重复请求本身不是错误，是分布式系统的常态。

数据库要记两类性质不同的事实。主状态是覆盖式的，始终只有一行在更新，回答「当前在哪一步」；事件流是追加式的，单调递增绝不修改历史，回答「我们是如何走到这一步的」，也是断线补发和事后复盘的依据。

run_events 的 sequence 单调递增序号是断线重连的关键。前端重连时只需带上 Last-Event-ID，后端通过 sequence > N 即可瞬间补发丢失的事件帧。

Chatbot 的 messages 记录「人和 AI 说了什么」，Agent Harness 还必须记录「系统做了什么，以及它是如何做到的」。只存一句「已为您退款 39.9 元」，你不知道它查了什么、调了几次模型、退款是否真的成功、消耗了多少 Token、谁批准了这次操作。

垂直 Agent 的「垂直」并不主要来自 Prompt，而来自围绕专业工作流设计的 Harness。只换一段系统提示词，只能让通用 Agent 说话像科研人员。

把每个数据库单独包成一个 tool，模型的选择错误率会随数据源数量一起上升。加一层 Connector 收敛成 search 和 fetch，数据库可以继续增长而动作空间保持稳定。

对话记忆不等于计算状态。Agent 能在对话记录里「记得」刚做过什么，却无法继续操作刚才的计算现场——除非 Kernel 按 session 复用。

Artifact 不只是让界面更漂亮。它是一种约定好的结果包装格式，告诉前端「这份数据是什么、应该怎样展示」，把原始坐标变成可旋转的蛋白质模型。

对于普通问答用户可能只关心最后一句话，但对于科研工作，过程本身就是信任的一部分。

Agent Loop 负责的是一次运行内部如何行动，Loop Engineering 负责的是多次运行之间如何持续推进工作。判断是不是 Loop Engineering，关键不是代码里嵌套了几个 while，而是看那个负责发现工作、检查结果、记录进度、启动下一轮的人，有没有被系统替代。

架构上的外层不等于循环上的外层。Claude Code 的 Supporting Systems（权限、Hooks、Memory、Session、MCP）确实包在 Runtime 外面，但它们只是在支撑 query_loop 运行，不会在 CI 失败后主动生成下一次 Agent 任务。

可靠的 Automation 不是定时器本身，而是「触发条件 + 任务蓝图 + 实例化 + 入队」的完整链路。闹钟只负责响，它不能直接代替一张工作单。

并行不是多开几个对话框，而是先隔离它们会修改的环境。没有 Worktree，就像让三位程序员共用一台电脑同时编辑同一份文件，Agent 数量越多冲突反而越快。

能重复运行的脚本不等于可靠的 Loop。可靠的 Loop 必须知道何时继续、何时重试、何时恢复，以及何时承认自己做不到——对应 CAS 乐观锁、周期性 Resync 扫描和自动恢复次数上限三道护栏。

对话式交互门槛低、正反馈快，但人类成为了整个系统的性能天花板。一旦你停下，工作流就停止了。

工程师的角色从「执行者」变成「循环设计师加审核员」。过去写代码定义产品，AI 早期写 Prompt 指导模型，现在设计 Evals 和停止条件来约束系统。

解决 Agent 失忆不靠塞更多上下文，而靠一个状态文件记录「尝试了什么、通过了什么、还剩什么」。第二天 Agent 醒来读的是这个，而不是昨天几万 token 的废话日志。

自己写代码的模型往往会陷入幻觉，觉得自己写得无懈可击。要拉起带批判视角的 Sub-agent 来守住质量下限，这就是自动化的负面评测。

Loop 只是放大了杠杆。懂业务的人用它清理技术债、把精力投入更底层的架构思考；试图逃避思考的人只会用它埋下更多看不见的隐患。

Agent 自进化并不总是发生在模型参数本身，更多时候发生在模型外围的系统里——记忆怎么更新、prompt 怎么改写、工具怎么生成、代码怎么回滚。它不是模型突然有了生命，而是人类工程师搭好了一个可持续试错、评估、选择和沉淀的循环。

把大模型接入进化循环只需三步：变异（模型基于当前瓶颈提出新代码或新 prompt）、评估（脚本在沙箱里运行并给出量化评分）、选择（分数变高就保留，变低或崩溃就回滚）。

大模型自己是不知道绝对对错的，必须由环境提供进化压力。有了一把标尺（文本评价或数值奖励），Agent 才知道自己的突变到底是进化还是退化。这是让飞轮转起来最核心的一点。

autoresearch 里被进化的是 train.py 这套训练系统——模型架构、优化器、超参数、训练循环，而不是外层大模型自己的权重。长期保留下来的是更好的代码架构、git commit 和实验记录。

真正有价值的不是 LLM 生成代码的速度，而是人类工程师如何定义那个「5 分钟」、如何设计那个 val_bpb，以及如何规定什么可以改、什么绝对不能碰。

真正决定 Agent 下一阶段壁垒的，不再是单纯的智商比拼，而是能否构建一套机制，让它像人类一样沉淀经验、自我进化。

做梦机制在本质上复刻了人脑的记忆巩固过程——白天像海绵一样高频吸收短期工作记忆，夜间自动回放经历，强化有价值的节点、剔除冗余噪音，把碎片化输入整合成稳固的长期认知。

把经验沉淀从实时的、昂贵的上下文中剥离出来，转为异步离线处理，是走向企业级智能体平台的必经之路。

干活的 Agent 与打分的法官必须物理隔离。评估器在独立的上下文中对照 Markdown 评分标准打分，避免了 Agent 陷入自我证实的逻辑盲区，也让每一次做梦沉淀下来的经验都经得起检验。

Dreaming 永远不会直接污染原始的输入记忆库，它输出的是一份全新的记忆。开发者可以实时查阅它写日记的过程，随时打断或审查结果，甚至指令它今晚该做什么主题的梦。

Claude Code 更像一个面向开发者的 coding agent runtime，OpenClaw 则是面向多入口、多设备、多权限场景的通用 Agent——它要解决的核心矛盾是能力开放与行为可控之间的张力。

Channel 层把外部世界与内部处理完美隔离，Agent Runtime 永远不需要知道这条消息来自张三的微信还是李四的飞书，它只负责接收标准化的信封。这种可插拔设计极大降低了拓展渠道的边际成本。

HTTP 像写信，客户端不发问服务器就永远不能主动搭话；WebSocket 像打电话，信道一旦建立双方随时可以开口。Agent 的长周期任务必须靠后者，才能把流式输出和后台进度随时广播给前端。

让模型看网页截图猜像素坐标，像让盲人看红绿灯。OpenClaw 提取浏览器的 A11y Tree，把网页解析成带标记的结构化节点，模型直接下达「点击 A1 按钮」的指令。

真正的 Harness Engineer 不假设模型不犯错，而是建立 Gateway 来鉴权、用 Node 沙箱来阻断、用 Runtime 压缩来抵抗遗忘。不越权、不搞破坏，是 AI 走向实用的底线。

Claude Code 的本质可以压缩成一个极简公式：Claude Code = LLM + Harness。除了模型本身，其余所有部分都是 Harness——内层是 query_loop 这条运行时流水线，外层是入口装配、能力系统、约束扩展、持久化上下文四类支撑基建。

理解 Agent 最关键的一步在 Phase 4：Python 执行完工具后，代码会把结果打包成 ToolResultBlock，并伪装成 UserMessage 塞回 messages 列表。模型下一轮看到的「工具结果」，在数据结构上就是一条用户消息。

系统并不呆等模型把所有字打完。当流式输出中识别到安全的读取类工具被触发时，直接让 Python 并发去执行，这是响应速度的关键设计。

循环里记忆的沉淀发生在两个节点：一是 token 预算触顶时把旧消息总结成一条边界消息（低成本地把上下文转成记忆），二是主循环结束后把完整 Transcript 存入文件。

Claude Code 的归档没有选择向量数据库，而是「本地保存 + 渐进式加载」的极简设计。这个取舍换来了完整的 Rewind 能力——用户撤销某步操作时，记忆状态机可以精准回滚，不留干扰数据。

在大脑、手和会话日志同处一个容器的架构里，Agent 是一只娇贵的宠物——沙盒里一个死循环就能让整个容器崩溃，几十轮的进度灰飞烟灭，而工程师因为容器里有用户私有代码甚至无法登进去 Debug。

早期 Claude 3.5 会在 token 接近上限时产生「上下文焦虑」草草结案，工程师为此在 Harness 里加了强制压缩；但压缩是不可逆的破坏，而当模型升级到 Opus 4.5 不再焦虑后，那段代码反而成了枷锁。

脑手分离让鉴权问题迎刃而解：凭证由外部 MCP 代理服务持有，代理验证权限后把代码拉下来挂载进沙盒。Agent 永远不知道密码是什么，即使被注入恶意指令，在四面环壁的沙盒里也偷不走东西。

外置的、只追加不修改的 Session 事件日志才是 Agent 真正的长期记忆库，上下文窗口只负责当前的思考推理。有了它，Harness 可以放心地清理上下文，也可以在崩溃后靠 wake(sessionId) 完美恢复。

一切被解耦为标准接口后，轻量的 Harness 可以立刻启动、只在真正需要写代码时才拉起沙盒，首字返回时间大幅缩短；同时天然支持一个大脑操作多个沙盒，或把控制权移交给专门的子大脑。

除了模型本身的权重和推理能力之外，我们写的每一行代码、每一个配置、每一段执行逻辑，全都是 Harness。如果你不是模型本身，那你就是 Harness。

Harness 工程的本质是以终为始——想要 Agent 具备什么行为，就在 Harness 中为大模型设计相应的外部套件。这个视角能把 RAG、MCP、沙盒、压缩、Skills、Plan-Act-Reflect 这些零散概念全部串起来。

Agent 表现不好，绝大多数时候不是模型太笨，而是 Harness 配置有问题。LangChain 完全没换模型，仅靠自我验证回路、确定性上下文注入和死循环拦截，就把 Terminal Bench 2.0 得分从 52.8% 提到了 66.5%。

每当发现 Agent 犯了一个错误，不要指望它下次能自己变聪明，而是要去做工程化设计——改隐式提示词、写自动化测试脚本作为拦截器，确保它永远不会再犯同样的错误。

压缩本质上是有损的，长上下文一定会腐烂。拉尔夫循环给出的解法是物理阻断——用 while true 脚本让每个子任务都在一个全新实例中运行，状态外置到硬盘上的计划文件里，让硬盘成为真正的状态机。

当下绝大多数 AI 社交产品本质上是「内容消费品」而非「社交网络」。它们能提供情绪安抚，却无法满足归属感和被真实他者看见的确认感。

AI 在社交里真正有价值的位置是中间层：破冰代理、关系推进器、共同养成对象、社交编排器，而不是关系的一端。

小火人最厉害的设计不是虚拟角色多聪明，而是把「维系关系」这件抽象且容易被惰性消磨的事，变成了一个可以被共同投入的具体对象。

在社交赛道里 AI 未必要足够强，只要机制足够对，就可以比一个完美的赛博情人更具社交张力。

AI 最该做的不是抢戏，而是在冷场时抛话题、在快要断联时制造契机、在两人热聊时识趣退场。它应该懂分寸，而不是这段关系里的第三者。

给 Agent 什么工具，取决于模型现在有多聪明。工具太简单会限制模型发挥，太复杂模型又无法理解，要精准测算它当前的能力边界。

哪怕设计再精妙的工具，只要模型在推理链条中不理解、不爱调用，就是无效设计。AskUserQuestion 最终版成功的原因就是「模型喜欢调用它」。

随着模型能力提升，曾经需要的工具可能变成束缚。为弥补过去缺陷而设的限制性设计，该拆除脚手架时绝不手软。

被动 RAG 很脆弱——切片策略、向量索引、环境依赖任何一环出问题，整个上下文召回就崩了。给模型 Grep 让它主动搜索反而更可靠。

扩展系统能力不一定要生硬地增加工具。通过渐进式披露和专用子代理，同样能优雅解决问题，还避免了上下文腐烂。

一个更强大的 AI 大模型并不意味着一个更善良的助手，它只会成为平台商业目标的更强放大器。

平台中心化在结构上被困在碎片化日志里——淘宝不知道你刚在小红书看了什么，抖音不知道你日历上的会议。真正的智能助理需要全局上下文。

端云协同架构下，云端返回的不再是推荐列表黑盒，它必须为每个候选项附上可解释的理由和机器可验证的元数据，向端侧证明推荐的合理性。

新型商业模式是把广告对象从「人」转移到「Agent」：平台为争夺订单向你的 Agent 竞价，Agent 提供商还可以把部分竞价费返还给用户。

真正的主权边界不是数据保存在哪里，而是协议层。谁定义了意图级 API 的格式、谁控制归因和结算规则，谁才是真正的主权者。

当前 LLM 患的是「顺行性遗忘症」——预训练前的知识完好无损，但部署后持久参数不再更新，永远活在上下文窗口这个当下的切片里。

用 RAG 给大模型外挂记忆，本质上是在给一个顺行性遗忘症患者疯狂递小纸条。面对简单事实问答很管用，但面对需要长周期跨越式推理的复杂问题，大量支离破碎的小纸条只会让信息处理能力过载。

论文指出深度学习架构的「拼装车」认知是一种幻象——注意力机制、前馈网络、优化器在本质上并没有不同，它们全都是联想记忆模块，唯一在做的事情就是压缩自己接收到的上下文信息流。

立体直觉的来源是更新频率的层次感。人脑不需要单一的全局时钟，高频神经元负责快速适应但记忆时间短，低频神经元负责整合持久知识。现在的模型只有两个极端，没有中间态。

未来每个本地 AI 智能体都可能在长期交互中演化出独一无二的底层权重，个性化不再是 prompt 里的前置条件，而是根植于神经网络底层的直觉映射——千人千面的内生参数，而非千人千面的数据库。

传统用户画像并不存在「向量化之前的那句文本」。它不是先写一句话再压成向量，而是直接从行为 ID 序列学出来的坐标点，所以那些数字天生就不可读。

LLM 介入之前，用户画像有三道围墙：不可解释（工程师只能说模型算出来分高）、交互被动（只能等用户点击去猜，不会开口问）、平台割裂（A 应用的向量到 B 应用就废了）。

LLM 不只是一个聊天工具，它天然就是人类偏好最好的解压缩器——能把「喜欢惊悚片」这样的浅层标签还原成「偏爱探讨人性阴暗面的黑色电影」这种真正的动机。

好的主动提问机制不是逢问必问，而是先用已有画像把能答的都答了，只有当缺失的信息会显著影响结果时才用最少的问题补齐。像优秀的服务员只在确认牛排几分熟时才打断你。

文本摘要可以作为跨模型、跨任务的通用偏好接口——源任务生成的文本画像直接喂给目标任务，无需微调或对齐层就能获得显著提升。用户画像因此有可能从平台的附属品变成用户可携带的数字资产。

传统 LLM 评估只看结果，但 Agent 评估必须同时看 Transcript。它可能靠瞎猜蒙对结果而思考路径完全错误，这种运气的成功就是埋在系统里的雷。

pass@k 衡量上限能力，pass^k 衡量稳定性。Demo 展示的通常是 pass@1，但产品交付时用户买单的是 pass^k。

一个好的测试任务应该让两个人类专家做都能得出相同结果。如果人类对「成功」的定义都有分歧，就别指望 Agent 能做对——必须先有人类的共识，才会有机器的智能。

能用代码确定性评分就绝不用 LLM。而且不要过度评估过程，如果 Agent 用了一种人类没想到的方法解决问题，那也算通过——评结果，别评路径。

当分数接近 100% 时评估就失效了。这时候要么换更难的任务，要么把这个评估集降级为回归测试，防止能力倒退。

复杂的 MLOps 仪表盘会把你和数据隔离开。最强悍的评估工具其实是电子表格，因为只有它才逼着你一行一行地读数据。

看数据要用社会科学的方法：先开放编码（随机抽 50 条错误日志，看到什么写什么），再轴心编码（归纳成分类体系），最后统计频次决定下周做什么。

不要把评估外包给开发人员。工程师看的是 Prompt 执行了、RAG 检索了、JSON 格式对了，结论是 Pass；PM 看的是用户要硬木地板你推了全地毯房，结论是严重的业务事故。

最危险的是那种没报错、没崩溃、语气还很礼貌，但完全搞砸了业务逻辑的错误。任何自动化监控都抓不到，只有真正看数据才能捕捉到。

裁判模型和人类标注一致性 90% 不等于完美。必须拆开那 10% 的不一致，分清假阳性和假阴性——用数据校准那把用来量尺子的尺子。

Agent 不应只是一个聊天窗口，而应该是一个智能服务的容器。每个子 Agent 都是封装好的垂直应用，有独立的 Prompt、工具集和记忆。

LUI 和 GUI 应该共存而不是互相取代。描述症状自然语言效率最高，但从十个医生里选一个，列表对比效率最高。

Agent 不等于聊天机器人，执行力才是灵魂。感知、决策、执行三步都走完，才算从「连接工具」变成「执行专家」。

医疗 Agent 的人格化设计就像当年的拟物化，是用户走向信任的临时桥梁。随着 AI 进化，这层人类的皮肤终会脱落。

PHA 最精彩的一步是主 Agent 回答前的自我反思——先问自己信息够不够、能不能直接去查用户的手环数据，而不是傻傻地问用户。

工业级 RAG 的解析阶段输出的不是一段文本，而是一棵结构化文档对象树——包含层级、样式与版面信息。如果只做 text = pdf.read()，标题、正文、页眉、表格混成一团，后面的切分必然一团糟。

切分阶段真正的产出不是文本块，而是元数据。chunk_id、section_path、page_num、prev/next_id 这张身份证，决定了系统后面能不能做答案溯源、检索加权和上下文扩展。只存文本和向量的 chunk 是没有灵魂的。

基于 Token 数的固定切分在保险条款面前会直接失效。切分点落在「但以下情况除外」之前，用户问「xx 保不保」就会检索到缺少除外限定的下半段，模型答「保」。必须换成基于文档树的递归切分加句子边界的智能 Overlap。

单一向量检索在金融领域有个致命弱点：对低频专业词汇不敏感。问「犹豫期退保扣费吗」，向量模型会召回语义相近的「退保流程」，却漏掉真正包含「犹豫期」精确关键词的条款。这是必须上 BM25 的理由。

所有这些解析、切分、检索的代码优化，本质都是在为目标业务场景买单。在金融领域是对「犹豫期」「免责条款」的精准召回，换个场景也许就是对速度的极致追求。代码只是工具，业务场景才是归宿。

不传 tools 参数也完全可以让模型用工具。SDK 内部做的只是一次文本格式化——把工具的 JSON Schema 转换成一段 System Prompt 塞进对话开头。工具调用的第一层本质是 Prompt Engineering 加结构化输出提取。

模型吐出 tool_call 之后并不会自己拿到执行结果。必须由代码捕获调用、在外部执行、把 User / Assistant / Tool 三条消息拼成新历史，再重新发一次请求。这是第二层真相。

多 Agent 本质上是把工具调用提升了一个抽象层级。单 Agent 的四种形态——单一调用、Router 路由、Chain 链式、并行——与多 Agent 的四种架构模式完全同构，只是调用对象从无状态函数变成了有状态的策略单元。

Deep Research 里的 Worker 不是无限搜索，而是跑一个带预算的 OODA 回路：由任务复杂度自动估算 max_queries 与 max_cycles，在预算内观察、评估缺口、生成下一轮 query。没有预算的循环在生产里就是烧钱。

多 Agent 协作的本质不是让模型互相聊天，而是定义一套清晰的 API 接口标准。Orchestrator 下发结构化 SubTask，Worker 回传结构化 Dict，全程没有一句自然语言对话。

读陌生领域的论文时，可以用「陌生领域类比法」建立心理模型——把视频生成模型当成预测下一帧的 LLM，把长视频生成当成长文本写作，把注意力集中在架构设计而不是公式上。

StoryMem 给记忆帧分配负数的时间索引，在数学层面告诉模型「这些画面发生在过去，是必须遵守的历史」，巧妙解决了记忆帧插入带来的时序干扰问题。

视频记忆的筛选标准不只是相关性，还有质量。StoryMem 用 HPSv3 打分把崩掉、模糊、有残影的帧直接丢弃——Agent Memory 通常只在乎事实对不对，这里还得在乎好不好看。

外挂一个显式的、结构化的记忆模块，比单纯加长上下文窗口更高效也更可控。发现 AI 记错了可以直接把那张图从记忆库里删掉，但在百万上下文的模型里很难通过 prompt 修正一个微小的幻觉。

永久保留最早的几个关键帧作为长期锚点，是为了防止漂移——如果只记最近的，生成到第 100 秒时主角的长相会因为多次迭代的误差累积而完全走样。

所谓「神秘模板」并不存在。在 WebUI 里选择 qwen 时，框架只是在后台把 ShareGPT 的 JSON 列表拼接成了一个带特殊占位符的超长字符串。模型看不懂 JSON，也看不懂 from: human 这种 key。

微调数据有三层形态：语义层（ShareGPT / Messages，给人和框架看）、渲染层（Chat Template，Jinja2 引擎负责翻译）、物理层（Raw Text 与 Token IDs，模型真正读到的东西）。搞混哪一层，格式问题就永远说不清。

完全可以抛弃官方模板自己造格式，只要保证「训练时喂的格式」和「推理时问的格式」一致就行。就像教鹦鹉说话，教 Hello 还是教你好都行，重复够多、规则够统一就能学会。

手写也能跑，但框架真正的价值在两个容易翻车的细节：自动生成 Loss 的 Mask 掩码（把用户提问位置填 -100），以及自动补上该模型专属的 EOS 停止符。索引算错一位，模型就会把指令当答案背诵。

用框架最大的工程意义是解耦：ShareGPT 保存数据逻辑，Template 保存模型实现。换模型时数据文件一行都不用动，只改 template: qwen 为 template: llama3。

只想让模型临时回答几个问题，写好 Prompt 就够了；想让它长期、批量、稳定地遵守业务规则并大幅降低推理成本，微调才是必经之路。

微调和 RAG 不是二选一。成熟架构是微调基座掌握通用话术、情绪安抚和 SOP 骨架，RAG 处理实时变动的信息——微调换的是低成本、高一致性与可控合规，RAG 解的是时效性和长尾。

脱敏必须用占位符替换而不是直接删除，否则模型会学到残缺的句式。宁可过度脱敏，也不要冒泄露隐私的风险。

流程引导型数据不能只造顺利的路径，必须加入用户中途反悔、没有订单号、不符合退货条件这些异常分支，否则模型在真实业务里一被打断就乱。

真实场景中愤怒样本很少，但训练集中必须超采样，否则模型在实战中遇到真正生气的用户会不知所措。情绪分布要刻意偏离真实分布。

大多数 Agent 的失败不是推理的失败，而是记忆的失败——因为我们正在试图用本质上无状态的大语言模型，去解决高度有状态的现实世界问题。

上下文是 LLM 单次交互能处理的文本量，临时且易失，本质是工作记忆；记忆是持久化的管理系统。记忆工程决定保留什么和遗忘什么，上下文工程决定让模型此刻看到什么。

即便强行塞入海量上下文，真正被有效利用的部分往往只有 20% 到 30%。输入越长注意力越分散，出现 Lost in the Middle，连简单的指令遵循能力都会退化。

多智能体系统的失败率高达 40% 到 80%，大量失败源于智能体间的不对齐：工作重复、状态不一致、通信爆炸、级联故障。

遗忘不是系统的 Bug，而是 Feature。系统需要智能地降低过时信息的权重，没有遗忘，记忆就会变成垃圾场。

Plan 模块不负责推理答案，它只负责输出结构化数据。所谓规划，本质上是模型写的一张工具调用剧本（JSON 动作列表）。

Act 阶段模型完全不参与。模型只出主意，真正调 API、查数据库的是人工写好的 Python 代码。这是最容易被误解的一点。

让执行不变成一团浆糊，靠的是四条朴素规矩：先把嵌套清单拍扁、严格顺序执行、统一记账格式、把每次调用包进 try/except。

反思听起来很玄学，但在代码层面它只是一个门控器：把问题和已有证据一起发给模型，问一句「够不够」。不够就再输出一轮搜索 JSON。

Agent 的入门门槛不是懂多少高深概念，而是能不能把「模型的决策」和「程序的执行」这条边界真正搞清楚。

RAG 系统本质上由两条异步流水线组成：离线处理（提取、向量化、存储）是消化系统，在线查询（Query 处理、检索、生成）是大脑。建立这个上帝视角，才能在出 Bad Case 时判断问题出在哪一条链路。

文档切块是 RAG 系统中最容易被忽视、却直接决定检索效果的环节。切得太碎模型看不懂上下文，切得太长检索噪音大且浪费 Token。

按 Token 预算动态合并（naive_merge）是工程落地中高性价比的切块方案——先用标点符号保护句子级的语义完整性，再用 Token 计数控制 Chunk 的颗粒度，避免了纯字符切分和纯段落切分各自的缺陷。

孤立的文本切片会导致张冠李戴。检索到「第三条：赔付金额为 50 万」时如果丢失了它所属的一级标题，模型可能会把重疾险条款当成意外险。层级栈加元数据是找回坐标的解法。

检索是一个漏斗模型：Query 优化扩充漏斗口、混合检索做粗筛、重排序做精选、最后交给 LLM 生成。每个环节的转化率都要单独看，才能量化出「引入重排后 Top 3 召回率提升多少」这样的结论。

所谓「大模型有记忆」，在代码层面就是每一轮都把完整历史重新拼接、重新发送给模型。模型本身始终是失忆的，记忆只是一个挂在外面的特殊检索源。

Function Call 的本质是四步：模型暂停并输出一张调用条子，程序在外部执行，把结果伪装成 tool 消息追加进历史，再重发一次。把 get_weather 换成 search_memory，原理一模一样。

Agent 和 Chatbot 的关键差异在于，Chatbot 只需记「谁说了什么」，Agent 还必须记「我做过什么」——否则会在失败的工具调用上陷入死循环。

多 Agent 记忆不是什么群体意识，工程上就是给每条记忆打上 user / task / agent 作用域标签的读写权限系统。隔离为了降噪，共享为了对齐。

记忆不是越长越好，而是越准越好。

API Agent 极速精准但能力边界完全取决于开发者开放了多少接口；GUI Agent 通用性强但慢且脆弱，软件一改版就可能点空。

完美的 Agent 是混合的：用 API 保证核心任务的效率守住下限，用 GUI 兜底长尾任务的覆盖突破上限。

理想的 CUA 证明了一件事——只要 App 能在屏幕上显示，Agent 就能通过看和点来操作它，不需要要求任何第三方开放接口。

Generative UI 实现了从「人适应软件」到「软件适应人」的反转：界面不再固定，而是根据意图现场生成。

AI 的角色经历了三重境界：API 时代是连接器，GUI 时代是模仿者，GenUI 时代是重构者。

LlamaIndex 把 RAG 浓缩成四行代码，但每一行背后都是一片可以优化的战场。

RAG 产品的护城河往往不在模型端，而在数据处理端：谁能把复杂文档解析得更干净，谁的效果就更好。

chunk_size 是检索颗粒度与 Token 成本的博弈，similarity_top_k 要按业务场景定。

RAG 不是大模型学会了知识，它只是在做一场开卷考试：检索系统 + 阅读理解系统。

从 Demo 到 Product，还差数据持久化、复杂文档解析和自动化评测这三件事。

H2A 的瓶颈不再是模型听不听得懂人话，而是带宽——上下文窗口。正如网络带宽限制视频清晰度，Context Window 限制了人机交互的深度，AI 聊久了会变笨，是因为它正在经历上下文腐烂。

MCP 相当于给 AI 世界发明了 USB-C 接口。以前让 Agent 连一个数据库要写各种胶水代码，现在只要外部服务遵循 MCP 标准，Agent 就能即插即用。

未来 AI 产品的壁垒，可能不在于用了哪个大模型，而在于你积累了多少独家的、标准化的 A2S 接口资源。

以前软件之间传数据用二进制，现在 A2A 通信的载体是自然语言加 JSON。这是一个巨大的范式转移——语义即协议，Agent A 输出的自然语言思考过程，成为了 Agent B 的输入。

A2A 架构直接决定产品的稳定性和成本：链路越长首字延迟越高，而每一次 Agent 之间的对话消耗的都是真金白银的 Token，设计不良的架构会让 Token 像水龙头没关紧一样流失。

程序员的技术黑盒正在白盒化，PM 可以也应该做「黑客级竞品调研」——实测体验、技术解密、开源复现三者交叉验证。看到差的，才能真正理解好的牛在何处。

实测中最致命的一幕：浏览器导航明确超时失败后，Agent 在下一步思考里幻觉自己成功了，并基于这个错误状态继续操作。工具失败后的状态确认是 Agent 可靠性的关键缺口。

PlanningFlow 复用 Agent 实例时既不重置 current_step，也不清空 memory，导致新任务发出无效消息序列而 API 400 报错，Agent 从此僵尸化，而 Planner 只是记录错误继续调度下一步。

OpenManus 和官方 Manus 之间最大的差距是上下文管理。OpenManus 只增不减地往 memory 里追加观察，撑到 Token 上限就失败；Manus 把上下文当最昂贵的资源来调度，文件系统才是它真正的上下文。

在循环中动态增删工具会让 KV 缓存失效，推理成本和延迟可能飙升十倍。正确做法是保持工具列表固定，在解码时通过遮蔽强制模型只从特定子集中选择。

RAG 没有死，它是这一切的地基。Agentic RAG 把 RAG 变成了工具箱里一个更智能的工具，Agent Memory 又在它之上增加了写入能力，三者是叠加而非替代。

Agentic RAG 和 Agent Memory 最大的区别就一个字——写。前者是动态只读，重点在更聪明地检索；后者是动态读加动态写，重点在管理信息。

Agent Memory 真正的挑战不在写入这个动作本身，而在写入之后的一整套记忆管理难题：写入策略、读取策略、遗忘策略、隐私安全。

一个只记不忘的 Agent 是灾难性的。用户搬家了却还记着旧地址、信息互相冲突，都需要时间衰减、使用频率、重要度评估和人工干预这些遗忘机制来兜底。

在海量文档检索或信息密度很高的企业场景下，RAG 的向量检索仍然是不可替代的底层能力，不会被记忆机制废弃。

Skills 用三层结构实现上下文按需加载：元数据始终常驻（约 100 Token）、正文在技能被触发时才读、捆绑文件由 Agent 按需读取，因此能力扩展几乎不受上下文窗口限制。

一个技能一旦被加载进上下文，就会一直留在上下文里，这是不可逆的，目前还没有对应的卸载机制。

Skills 不只是说明书，还是工具箱。把排序、计算这类任务交给 Skill 里的 Python 脚本，Agent 获得的是确定性和可靠性，而且脚本本身不需要进上下文。

构建 Skill 应该从评估开始，而不是先假想需求——先让 Agent 跑实际任务，观察它在哪里卡壳，再增量式地为这些短板补 Skill。

二手资料往往为了传播效果而浅显甚至失真。哪怕自己读一手资料形成的理解是片面的，被纠正时留下的认知也远比任何二手总结牢固。

AI PM 的演进路径是从软件 2.0 的「算法 PM」走向软件 3.0 的「Agent PM」，角色定位从算法的辅助者变成系统的设计者。

算法 PM 对应 Peter Deng 五种原型里的研究型，而 Agent PM 需要五种原型的合体——因为构建评测体系恰好用得上全部五种能力。

AI 让原型成本降低了 100 倍，「马车先行」成立：先在两周内把原型怼到客户面前，拿到反馈后再补一份小而精的需求文档。

在 Agent 时代，一个酷炫的聊天界面不重要，Agent 是否可靠地完成了用户的目标才重要。

不必强迫自己成为完美的「六边形战士」，一个优秀的 PM 团队应该是复仇者联盟，需要不同角色间的良性对抗。找到自己的优势区就好。

AI 时代 PM 不再靠文字定义产品，而是靠评测体系定义产品。以前 PM 写文档指导模型，现在 PM 写评测校准模型。

你无法在 PRD 里写一条「模型不允许预测未发生的世界杯结果」这样的规则，静态规则根本无法穷举所有幻觉。

高价值复杂场景该用 Workflows 而不是 Agent，因为 Agentic Search 很难找到可验证的 reward、输出不可控，而固化 SOP 能提升确定性。

AI 产品的需求不是写出来的，而是在错误中被发现的。PM 的「失败模式表」应该转化成约束模型底线的可执行代码。

AI 搜索不像传统搜索有清晰的后验信号（如点击率），用户看完答案就走了，所以必须依赖强大的先验评估。

是「智能体的十年」而非「智能体之年」。要让 Agent 真正工作起来大约需要十年，PM 应该拿这个时间框架规划长期路线图。

演示和产品之间存在巨大鸿沟。一个 90% 可用的 Demo 只是第一个「九」，每提升一个九都需要付出同等量级的努力。

对模型来说记忆是 Bug 而不是 Feature。知识在阻碍神经网络发展，方向应该是移除部分知识、保留「认知核心」，迫使模型去查询信息。

「如果我不能构建它，我就不理解它。」不要写博客、不要做 PPT，去构建代码让它运行起来，这是唯一的途径。

AI 编程进展神速是因为编程是纯文本的，且已有 IDE、版本控制、Diff 工具这些预建基础设施。扩展到幻灯片这类视觉空间任务会难得多。

推理能力是过去一年定义性的突破。在需要深度逻辑的产品场景里，它决定了你的产品是「懂你」还是仅仅「答你」。

现有基准测试很脆弱，AIME 这类测试对细节极其敏感、结果波动巨大。别被单一分数迷惑，要建更贴近真实场景的内部评测标准。

攻击性网络安全能力每 5 个月翻一番，快于通用 AI 能力的每 7 个月。设计 Agent 产品时安全必须是第一考量。

多数 Agent 工作流狭隘且重复，1 到 9B 的小语言模型通常足够胜任且成本低 10 到 30 倍。「SLM 优先、大模型兜底」能省下大笔开销。

AEO（答案引擎优化）时代来了。产品的可见性不再仅由搜索排名决定，而是越来越依赖 AI 模型的引用模式。

从 Chatbot 到 Agent，核心瓶颈从「怎么写提示」彻底转向了「怎么管上下文」。提示工程没有消失，它渗透进了 Agent 架构的每一个组件。

上下文工程的黄金法则是：在模型有限的注意力预算下，用信噪比最高的最小 Token 集合，驱动模型产生期望的行为。上下文不是越多越好。

优化工具描述带来的性能提升，远大于修改总系统提示。Agent 能否正确选用工具，九成取决于这个描述写得是否清晰、无歧义、无重叠。

智能体搜索不是「检索」，是「探索」。Agent 拿到的是文件名和 grep 这类轻量标识符与工具，在运行时自主决定要看什么——更像人只记住索引和书架，而不是背下整个图书馆。

子代理是「工具」而不是「团队」。拟人化的分工（PM 代理、程序员代理）跨代理沟通成本极高，而 LLM 并不受人类认知分工的限制。

大模型本身是无状态的，它没有任何记忆。所谓多轮对话，是工程师每次请求时都把之前的对话历史像前情提要一样重新打包发给模型。

模型内化记忆的知识，远比通过 RAG 临时喂给它的知识更深刻。前者是消化吸收过的，后者只是看了一眼小抄。

指令存在优先级金字塔，冲突时 platform 覆盖 system，system 覆盖 user。这就是为什么无论怎么诱导都无法让模型突破底线，以及为什么它会坚持角色设定。

在当前以 Transformer 为主的阶段，参数量大是知识记忆能力强的必要条件，72B 以上大致是基础知识水平达标的门槛。

把自己领域内的困难 case 记下来做成私人测试集，每次有新模型发布就跑一遍，十几分钟就能对它的能力边界和脾性建立体感。

FDE 不是驻场外包也不是解决方案架构师，而是「产品化咨询」——规模化地做那些不能规模化的事，靠着陆、扩张、抽象形成闭环。

大模型是强大的引擎而不是开箱即用的汽车。把引擎装进千行百业的复杂业务流程，才是所有 AI to B 公司面临的最大挑战。

在执行 FDE 模式的公司里，AI PM 最重要的用户是内部的 FDE。FDE 是客户解决方案的产品经理，AI PM 是核心平台的产品经理。

大多数公司没有 FDE 模式，优秀的 AI PM 必须成为「内置的 FDE」，先自己做 Demo 验证 PMF，再带着标准答案去找开发团队。

AI 时代 PRD 的首要读者不再是人类而是 AI，它本身就是一个上下文工程的产物。

CLIP 用 4 亿图文对训练，仅靠一句文本提示做零样本分类，在 ImageNet 上达到 76.2% Top-1，与有监督 ResNet-101 相当。

视觉语言模型让一个模型同时胜任分类、检测、分割，模糊了这些传统任务之间的界限，传统 CV 算法范式正被重新定义。

人与 AI 的协作关系在改变：过去人类是提供标注、手把手教模型的「教师」，现在是在推理阶段用提示引导模型的「导演」。

CV 产品的未来不在于构建最好的孤立分类或检测模型，而在于把视觉能力集成进更大的、具智能体特性的多模态系统。

大模型不会完全取代小模型。实时、移动端、边缘设备等场景仍需要轻量模型，命题从「改进小模型」变成了「小模型如何利用大模型」。

产品经理理解 CV 技术的抓手是核心四问：业务问题、输入输出、性能边界、落地成本。

分辨率翻倍会让像素数变成四倍，成本-质量曲线是每个 CV 产品都必须做的战略取舍。

从 SIFT 到 CNN，产品风险从「算法设计得对不对」转移到了「数据质量够不够」。

检测选 YOLO 还是 R-CNN、生成选 GAN 还是扩散模型，本质都是速度与精度的场景取舍。

架构优劣只是时间快照，今天最优的选择 18 个月后可能过时，产品战略要保留架构灵活性。

与其临近秋招才焦虑，不如把校招 JD 当作目标反推学习路径。JD 是这个岗位能力要求最诚实的一份说明书。

学技术概念时每次都追问一句「这个技术能用来做什么产品或功能」，这是 AI PM 区别于传统 PM 的核心壁垒。

还是要补 LLM 之前的机器学习和深度学习。知道没有 LLM 的时代问题是怎么解决的，技术直觉才扎实。

一个可交互的 Demo 胜过千言万语，是验证 PMF 最快的路径。个人项目证明下限，真实实习决定上限。

以 100 分为目标最终可能拿到 80 分，以 80 分为目标就只有 60 分。在力所能及范围内不断拔高要求更能激发潜力。

前端不应直接调用 Dify 的 API，所有 API 密钥必须放在后端。后端要同时充当业务逻辑核心和安全网关。

最快的 MVP 上线路径是 Dify 搭工作流、Lovable 生成前端、Supabase 直接做后端和数据库，前端和后端都不用自己部署。

任何东西部署到云端之前，先确保本地能完美运行，数据库尤其如此。一旦上了云，调试的难度和成本会直线上升。

在写下第一行代码之前就要初始化 git。它是唯一的后悔药，让你敢于尝试和犯错，因为永远可以回到上一个正常版本。

快速验证想法、拿到用户反馈、形成产品闭环，比追求一个完美的架构重要得多。这就是 AI PM 的「两周 MVP 冲刺」范式。

AI PM 要懂的技术不只是深度学习和 LLM 理论，还包括把产品思维快速落地的实践能力。

开发测试阶段不要考虑成本，直接用最强的模型。先摸到产品效果的天花板，性能上限决定了产品的想象空间。

把一大堆复杂 Prompt 塞给同一个模型节点会让它「精神分裂」，应该拆成多个专注的子任务分配给不同节点。

Prompt 里给几个高质量示例，比写几百字描述性指令有效得多。

不懂代码也能用 Cursor 开发 AI 应用，但一定要学会用 git 做版本管理。

评测是给 AI 做的一次全面体检加能力大考，目的是量出它的能力、行为和边界，而不是给出一个分数。

每一个 case 都必须亲自看过。AI 可以协助打分，但只有心里对所有 case 有清晰的理解，之后才提得出精准的优化方案。

安全与可靠性是一票否决项，一旦出现泄露隐私这类问题，无论其他维度多好都直接判为失败。

Agent 能挡住直接的恶意请求，却挡不住用善意伪装的社交工程攻击——这是评测中最容易被漏掉的一类高危漏洞。

评测的终点不是分数而是迭代，优化之后必须用同一套评测集跑回归，确认老问题修好且没引入新问题。

理解 AI 的前提是沉浸其中：先成为顶尖模型的重度使用者，再谈判断力。

读论文要带着问题批判性地读，重点是识别技术不足与落地鸿沟，而不是复述结论。

评测是 AI 产品落地的基石，也是 AI PM 的第一大技能——用评测驱动产研团队。

竞品调研要深入到「算法如何实现」的层面，而不是停留在功能对比。

AI 产品经理的核心是「双重同理心」：既理解用户，也理解 AI 本身。