大模型通识 / 大模型技术演进
22. 更强的模型为什么仍然需要工程保障
原文备份 · 第 23 / 26 篇 · 查看极客时间原知识库 ↗
本篇目录 · 8 节
来源：大模型技术演进
2025 年 11 月 26 日，Anthropic 公开了一组颇有代表性的开发经验：即使用当时先进的编程模型搭配 Agent SDK，让它跨多个上下文窗口持续开发网页应用，工作仍可能中途失去交代，或者只完成部分功能就宣布结束。团队为此引入了环境初始化、进度记录和逐项推进等安排。长任务 Agent 工程报告
这与年初 Coding Agent 带来的震撼形成了值得注意的对照。人们已经看见 AI 读项目、改代码、运行命令，开始把更大的任务交给它。可当一次任务从几分钟延伸到多个会话，问题不再只是“这一段代码会不会写”：下一轮知道上一轮做了什么吗？它说完成的时候，用户真的能用吗？
这不是模型能力提升失去了意义。恰恰是因为能力提升，过去难以交给通用 AI 的长任务开始进入试验范围，原本藏在人工操作里的交接、检查和恢复工作，也必须进入系统设计。
上一篇讲清了模型怎样连接工具、资料与其他 Agent。这一篇讨论连接之后的事：怎样让系统看到合适的信息、记住必要的状态、检查结果，并在出错时停下来或恢复。观察截止日期仍为 2026 年 10 月 3 日。
从一段提示词，到每一步都要组织的信息
早期开发者调试一个摘要应用，常常主要修改提示词：换一种角色描述，补一个示例，规定输出格式。到了 Agent 阶段，模型每一步看到的内容都在变化。除了原始任务，还有搜索结果、文件片段、工具错误、先前计划和新的用户要求。
2025 年 9 月，Anthropic 用“上下文工程”讨论这类问题：需要管理的不只是提示词措辞，还包括运行过程中进入模型的信息。其关注点是怎样选择、组织和维护上下文。上下文工程文章
用复习助手来理解，这个区别很具体。用户希望根据本周笔记制卡，系统却可能同时拿到去年的讲义、上一次任务的错误记录、已经失效的写作要求和几十个工具的说明。模型看到的信息多了，却未必更接近当前目标。
上下文工程要处理的是选择：当前任务是什么，哪些资料确实相关，哪些是已确认事实，哪些只是待验证猜测？整篇笔记现在就需要读吗，还是先看目录再按需取段落？已经解决的错误日志，还需要一直放在前面吗？
长上下文扩大了可容纳的信息量，却不能代替这些判断。2023 年的《Lost in the Middle》研究就观察到，在其测试任务与模型中，相关信息的位置会影响利用效果，处于中间的信息尤其容易被忽略。这个历史结果不应直接当成所有新模型的固定表现，但它提醒开发者：能放进去与能用好，是不同的评测问题。原始论文
因此，摘要、检索和按需加载仍然有价值。它们减少当次必须处理的材料，也可能降低输入开销与等待时间。不过摘要同样可能漏掉关键限定。一个可恢复的系统应保留原始资料的位置，让模型有机会重新查证，而不是只留下无法追溯的一段压缩文字。
记忆：保存了什么，又在什么时候取回来
上下文与记忆经常被混用。可以先作一个实用区分：上下文是模型这一步实际看到的信息；记忆机制负责把信息留到以后，并在需要时取回来。 保存在数据库里的内容，如果没有进入当前任务的信息流，模型不会因为它“存在”就自然知道。
LangGraph 的文档区分了会话范围内的短期记忆，以及跨会话保存用户或应用信息的长期记忆；前者与任务状态和检查点相连，后者需要单独的存储与读取安排。记忆机制说明
对于复习助手，有几种信息值得区别对待：用户长期偏好“一张卡片只考一个知识点”；本次任务已经生成了十张草稿；某条笔记的原文在哪里。这些内容分别对应偏好、工作进度和外部资料。把它们全部塞进一段聊天摘要，会让更新和查错都变得困难。
记忆也需要修正。用户说“这一次详细一些”，不一定是在修改永久偏好；模型推断用户已经掌握某个概念，也不应未经检验就成为长期事实。如果错误信息被反复取回，系统会稳定地重复错误，而不是越用越懂用户。
跨会话接续更需要明确状态。例如，保存“卡片已经生成，等待确认”，就比保存“今天做了很多复习工作”更有用。最好还能找到草稿、来源和上一次检查结果。
这里还藏着一个普通软件工程问题：程序可能已经保存成功，但在返回确认前断线。恢复后如果直接重做，就可能保存两份。常用的应对思路是给同一次业务操作一个稳定标识，让重复请求不会重复产生结果，这通常称为幂等。它需要写入逻辑配合，不能只让模型在记忆里写一句“不要重复”。
评测：先把“做好了”变成可以检查的条件
当模型给出一篇流畅回答，人很容易凭印象判断质量。但一个任务型应用需要更具体的完成标准。
2026 年 1 月，Anthropic 的 Agent 评测文章明确区分了运行记录与环境中的最终结果：Agent 说自己做了什么，与系统最终留下了什么，需要分别检查。文章也讨论了代码、模型和人工等不同评分方式。Agent 评测方法
对我们的复习助手，以下是一组教学构造的检查用例，不是已经运行得到的成绩：
| 输入或情境 | 应当检查的结果 |
|---|---|
| 笔记中有清楚的定义 | 卡片准确表达定义，并能回到原文 |
| 笔记缺少问题所需的信息 | 标明依据不足，不编造确定答案 |
| 两份资料对同一结论有冲突 | 呈现差异，不擅自消除冲突 |
| 用户尚未确认草稿 | 正式卡片库没有新增记录 |
| 保存后断线，再恢复同一任务 | 没有重复卡片，能够查到已有结果 |
这些条件里，有的适合代码检查，例如字段是否存在、正式库是否被修改。有的需要人阅读，例如卡片是否真的考查了一个完整概念。也可以让另一个模型按明确标准辅助评分，但“模型给模型打分”并不会自动得到客观答案，仍要用人工样本校准。评测与人工标注校准
评测因此不只是跑一次行业榜单。公共基准帮助我们观察某类能力，自己的用例才直接回答“换模型、改提示词或改检索之后，我的应用有没有变好”。比较时还要保留相同输入和测试条件，避免一边换模型，一边换资料，最后无法解释差异。
同一用例也可能出现不同结果。对于重要流程，可以重复运行观察波动，而不是挑出最好的一次截图。每次测试需要从合适的初始状态出发，不能让上一次留下的卡片帮助下一次“通过”。
个人项目不必一开始就建立庞大的评分系统。从几条最能代表需求、最容易出错的用例开始，保存已出现的失败，再检查后续修改是否让旧问题复发，通常更容易形成持续改进的习惯。
追踪：知道失败发生在哪一步
评测告诉你结果是否达到标准；追踪则帮助你解释这次结果是怎样产生的。
这类需求早在第一轮应用扩张时就出现了。LangChain 团队于 2023 年 7 月介绍 LangSmith，面向大模型应用的调试、测试、评估和监测；2024 年 2 月 15 日宣布正式可用。它不是等到长任务 Agent 流行之后才出现的产品。早期公告、正式可用公告
Langfuse 在 2023 年 7 月的发布文章中，也已经把质量、成本、延迟与复杂调用的调试列为核心问题。它展示了另一条开放源码、可自行部署的产品路线。Langfuse 早期介绍
一条 Trace，调用追踪记录，可以把某次请求里的模型调用、资料检索和工具执行关联起来，并记录相应输入输出、耗时等信息。Langfuse 当前文档以这种结构说明应用追踪；实际能看到多少，取决于你接入和记录了哪些步骤。追踪机制说明
假如某张卡片写错了，追踪可能帮助你区分：原文提取错了，检索拿错了段落，正确资料没有进入模型请求，还是模型读到资料后仍然生成了错误答案。这几种原因对应完全不同的修复方向。
同样，用户说应用很慢，未必是模型单次生成慢。也可能是搜索服务等待太久，或者系统在重复进行无效重试。只看到最终回答，往往很难发现这种差别。
LangSmith、Langfuse 这类工具帮助收集与查看证据，并不会自动替应用定义正确答案。它们也不会凭空看到模型未公开的内部思考，更不是装上以后就能自动监控电脑里的所有 Agent。应用需要相应集成，记录内容还应避开密钥等不必要的信息。
对于很小的项目，带任务编号的结构化日志就可以作为起点。随着步骤增加，再引入能够关联调用、比较实验和查看成本的工具。关键是让失败能够被定位。
沙箱与权限：把执行能力限制在合适的范围
当 AI 只能生成文字时，错误通常先表现为一段坏答案。当它可以执行命令、改文件和访问网络，错误就可能变成真实的软件操作。
2025 年 10 月，Anthropic 介绍 Claude Code 的沙箱设计，重点包括文件系统与网络隔离。这类产品变化说明，随着执行能力增强，限制运行环境也成为 Agent 配套的重要组成部分。沙箱工程说明
另一个问题来自外部材料本身。2023 年已有研究演示了间接提示注入：攻击者把指令藏进模型可能读取的资料，诱使应用偏离用户任务。对复习助手来说，笔记里出现“忽略原要求”不应变成新的操作授权。外部资料与用户指令需要区别处理，执行环境也要限制错误动作的影响。间接提示注入研究
沙箱可以理解为受限制的运行环境：程序能够访问哪些文件、连接哪些地址，由环境和配置约束。它与审批机制相关，却不是同一件事。审批回答“这次操作是否允许继续”，沙箱限制“即使程序开始执行，它能接触到什么”。
以 Kimi Code 为例，其文档提供了工具操作的确认流程以及不同权限模式。减少确认次数改变的是交互与授权方式，不能据此推断操作已经获得了操作系统层面的隔离。Kimi Code 交互与权限说明
对复习助手的开发，合理的起点是使用测试笔记与测试数据库，让调试过程有清楚的影响范围。对已经提供给用户的应用，则可以把“生成草稿”和“写入正式卡片”设计成不同动作，后者在满足条件后再执行。
沙箱也不会检查一张卡片是否准确。它帮助限制操作影响，内容质量仍然需要评测；审批也不应成为替代所有设计的按钮，让用户在看不懂操作时不停点击同意。
Harness 与 Loop：把这些安排组织成能运行的系统
前面几节看起来分散，其实都围绕同一个问题：模型怎样在一个有状态、有工具、有反馈的环境里持续工作？
在 Agent 语境下，Harness 通常指围绕模型的执行支撑系统，例如把任务和资料交给模型、执行工具调用、收回结果、管理状态并决定何时继续。不同项目的范围不完全相同；它不是一个统一协议，也不是换了名称的模型。Agent Harness 的定义与评测对象
“模型加上 Harness”才是用户实际接触到的工作系统。同一个模型，如果一个环境允许它运行测试、读取错误日志，另一个环境只能收发文字，完成软件任务的方式和能力边界就会不同。
到 2026 年 2 月，OpenAI 的 Harness Engineering 文章又把讨论推进到工程环境本身：怎样让项目知识可查，怎样让应用行为可观察，怎样把要求变成检查和反馈。那是团队的一项开发实验，不是所有项目都必须照搬的标准流程。OpenAI 工程报告
理解 Loop，则要看系统怎样根据反馈进入下一轮。2024 年末 Anthropic 的 Agent 方法文章已经强调：执行时需要从工具结果等环境反馈中判断进展，也需要完成条件和迭代上限。Agent 循环与停止条件
本文把“Loop 工程”理解为对这种循环的设计，不把它当成一个有唯一规范的独立标准。一个有用的循环需要回答：这轮做什么，结果怎样检查，失败信息怎样进入下一轮，什么时候结束或交给人处理。
flowchart LR
A[读取任务与已有状态] --> B[选择并执行下一步]
B --> C[检查结果并保存进度]
C --> D{是否满足完成条件}
D -->|是| E[交付结果]
D -->|否| F{能否在预算内继续}
F -->|是| A
F -->|否或缺少必要信息| G[停止并说明待解决问题]
这是教学示意，不代表所有 Agent 都采用相同实现。循环还要能响应用户中断、权限不足和工具故障。重试也应有理由：网络暂时失败可能值得再试；同样的错误输入反复发送，通常只是在增加开销。
这里有两个时间尺度。任务内部的循环是“执行、观察、调整”；开发者改进应用的循环则是“收集失败、加入用例、修改系统、重新评测”。后一种循环可能更新提示词、工具、数据或代码，并不自动意味着模型进行了训练。
用 Kimi Code 开发时，怎样把方法落到一个小功能上
最后回到一个具体开发场景：让 Kimi Code 为复习助手增加“确认草稿后保存卡片”的功能。下面是教学设计，用来理解工程分工，不是已经执行过的开发记录。
这里有两个系统：Kimi Code 是帮助我们修改项目的开发工具，复习助手是最终给用户使用的应用。前面讨论的工程原则对两者都有价值，但给复习助手接入追踪，不等于自动记录了 Kimi Code 内部的全部运行过程。
开始时，先让 Kimi Code 看清已有的草稿数据结构、保存入口与测试方式，再明确三个完成条件：未确认时不写入正式库；确认后能够重新查询；同一次操作重试不产生重复记录。
这一步同时提供了相关上下文和可检查的目标。接着让它完成一个范围明确的修改，在测试数据库上运行对应检查。如果检查失败，就把实际错误交回下一轮，而不是只补一句“认真一点”。
检查通过后，还要从用户路径验证：打开草稿，确认保存，重新进入卡片列表，核对内容和数量。单个函数测试通过，不能直接证明页面按钮与后端连接正确。完成记录应写明修改位置、验证结果和未解决事项，方便中断后接续。
如果你无法运行数据库，合理的状态是“代码已修改，保存链路尚未验证”，而不是让 Agent 多说几遍已经完成。区分这两种状态，比选择一个听起来更先进的工程术语更有用。
能力继续提高，工程也会继续变化
更强的模型确实可能减少某些复杂提示、专用补丁和失败重试。工程不是越堆越多才算成熟；当新的能力让旧措施失去价值，也应通过评测把它们简化。
与此同时，应用范围还在扩大。一次摘要与一个持续运行的个人 Agent，需要承担的状态、工具和结果责任并不相同。模型调用价格下降，也不保证整个任务更便宜：重试、检索、评测、运行环境和人工检查都可能占用资源。真正要观察的是在可接受质量下，完成一项任务需要多少时间和成本。
从提示词到上下文，从日志到追踪，从单次回答到执行循环，工程方法始终跟随实际瓶颈变化。理解这些方法的目的，是在项目出问题时知道该检查哪一层，也知道模型升级能够解决什么、仍需要程序保证什么。
下一篇将把这段历史重新连起来：模型能力、应用形态、生态工具与尚未解决的问题，怎样共同构成今天的大模型开发图景。
下一篇：23｜把历史连起来：能力、应用、生态与尚未解决的问题
返回：第 0 部分大纲