26｜深度应用：把组件组合成能解释的工作系统
本章目录
本章预备知识
应用蓝图不是技术名词拼盘，而是“允许哪些输入、寻找什么证据、做哪些动作、怎样证明结果”。同一基础框架在问答、编码和GUI里的风险不同。
本章各题列出所需基础。可先完成相应基础课，也可通过自检确认掌握程度。
进入深读前的小检查：给企业问答与自动修改生产数据分别列出最小验证，解释为什么前者引用检查不能替代后者的权限与执行确认。
术语带虚线时可点击速查。公式中的字母先看定义；不要用猜缩写替代推导。
这里不是列举“企业知识库、研发Agent、研究助手”三个名词，而是解释请求在这些应用内部怎样逐步变换。蓝图是本书提出的工程设计，不宣称某个商业产品按此完整实现。
沿着对象与状态理解本章
从失败发生的位置选择组件：信息没取到先改检索，已有证据却读错再看上下文与模型，执行未知先查状态。不要同时加Memory、多Agent和Review后再猜是哪一项有效。
下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制，不与本章其他独立例子的数值暗中接续。
先找错误发生在哪层，再谈换模型
什么时候该改Prompt、检索、记忆或模型？
一个错误答案可以来自不同原因。模型根本没拿到新版本时，增加推理时间不能补出缺失事实；检索已经拿到新版本却被旧记忆覆盖时，需要修上下文与记忆使用规则。选择修复层应跟随证据，而不是看到失败就再加一个Agent。
输入与适用条件：构造“旧配置被当成当前配置”的诊断案例；不以单次观察就宣称确定因果。
1 / 6 · 现象
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
先写清楚哪句话错、正确证据是什么，避免只说“感觉变差”。
本步状态由图形与说明共同给出。默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
为什么需要
避免无目的地叠Prompt、规则、模型和审查环节。
怎样实现
按原文→索引→检索→上下文→推理→行动→核验逐段定位。
可能的代价与误解
同时改变多个因素后只看总成功率，无法解释哪项改动起作用。
如何判断是否做对
同任务、同版本、同预算对照，保留失败样本与可复查轨迹。
Q101｜企业知识问答怎样做到不仅能回答，还能证明回答适用且不过期？
核心回答
把问答拆为身份与时间范围确定、证据检索、适用性检查、主张生成、引用验证和答复。检索相似度只负责找候选，版本、权限和条件决定候选是否能作为依据；必要时承认证据不足，而不是补造政策。[DPR][CTXRETRIEVAL]
一次“我能否报销这笔费用”的运行过程
接收问题时先确定用户所属组织与费用日期，避免拿当前政策回答历史报销。检索入口用身份过滤可读文档，再按政策生效时间筛选或展开候选。解析应保留主条款、例外、金额阈值和附件关系，不能只返回“可报销”那一句。
假设候选包含普通差旅政策、海外差旅例外和一个过期版本。系统应把它们表示成带来源和有效区间的证据，而不是拼成无顺序段落。生成前列出需要回答的主张：费用类型是否覆盖、金额限制、是否需批准。每个主张必须有适用证据；若缺费用地区，就说明这一条件尚未确定，而不能假定普通规则适用。
最后检查引用真的指向支持该主张的文本。引用存在不等于支持：一条关于交通费的段落不能证明住宿上限。答复中分开“政策明文”“根据所给条件的推导”“仍需确认的资料”。涉及真实报销决定时，还需遵循组织授权，回答工具不应自动取得财务批准权。
企业问答怎样把答案每个分句接回证据
输入与条件。问题：“试用用户周六申请第6天的退款，可以吗？”虚构政策写“7天内且仅工作日受理”。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1拆事实 | 试用、第6天、周六、申请 | 确定要匹配的条件。 |
| 2检索 | 取得当前试用政策完整条款 | 不只取“7天内”四字。 |
| 3逐条件 | 6≤7满足期限；周六不满足工作日 | 两个条件是且，不是或。 |
| 4回答 | “期限内，但周六不满足受理日条件” | 分别关联同一条款中的不同条件。 |
| 5避免扩写 | 政策未说顺延到周一是否仍可 | 不自动补一个顺延承诺。 |
把过程连起来。可信问答需要条件组合和证据边界，不只是相关文档加流畅复述。
边界与反例。政策完全虚构，用于说明逻辑，不对应真实退款或法律权利。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
追问：为什么不把整本制度放进大上下文？
小型单一制度可以直接完整读取，未必需要RAG。但文档多、权限不同、频繁更新时，全量上下文增加成本与冲突处理负担。选择应基于规模、更新率与任务表现，而不是默认向量库或默认超长上下文。
追问：用户要求“给一个确定答案”怎么办？
确定性来自条件和证据，不来自强硬语气。可明确回答在已知条件下能确认什么，并指出哪个缺失条件会改变结论。不能因用户偏好确定表达，就忽略证据矛盾或把未知字段填成有利值。
追问：问答缓存的键为什么不能只有问题文本？
同一句问题可能来自不同权限用户、不同组织和不同日期；知识版本也会变化。缓存必须绑定必要的身份范围、证据版本和适用条件，或使用安全的共享范围。否则缓存会绕过检索阶段的权限控制。
Q102｜一个仓库修复Agent从接单到交付，最少需要哪些内部对象？
核心回答
至少要能表达任务目标与约束、当前代码快照、候选解释与证据、修改集、执行结果和验收状态。可以先用文件和少量结构化记录实现，不必立即建设复杂平台。关键是这些对象之间有明确关联，而不是全部混在聊天历史中。[HARNESS][SWEBENCH]
以exclude路径错误为例
接单时记录“项目根目录相对路径匹配；不改变现有包含规则；修复后保留未排除文件”。取到仓库版本r42后，先运行最小失败测试，保存命令、环境、返回码与失败断言。随后沿调用链检查路径从调用者进入匹配函数之前是否已归一化。
找到候选根因后，Agent应该能回答“哪条证据排除了其他解释”。例如匹配库本身在相对路径上正确工作，而调用者传绝对路径，才支持修复归一化入口。改动形成独立patch，应用时核对旧内容或版本；若用户同时修改了文件，重新读取并协调，不能覆盖。
验证先运行根因相关测试，再根据影响面增加回归。最终交付绑定当前工作区版本：修改了什么、为什么正确、测试实际运行了什么、哪些未验证。模型可以解释这份证据，但不能用解释替代运行结果。是否提交、推送、部署由授权范围决定，不由“任务完成”四个字自动扩权。
从Bug描述到补丁交付，哪些对象必须一致
输入与条件。任务B17要求保留ab目录；补丁P应用于基线v7，得到v8；测试R的运行对象是v8。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1需求对象 | B17包含a、a/x、ab/y的预期 | 后续验收有稳定目标。 |
| 2证据对象 | 源码定位到v7的startswith | 根因依据可核对。 |
| 3补丁对象 | P声明基线v7与改动范围 | 应用失败时不把部分结果当完整补丁。 |
| 4测试对象 | R记录v8、命令、退出码与边界断言 | 与交付版本一致。 |
| 5最终交付 | 交出v8和R | 不能改出v9后仍沿用v8的测试记录。 |
把过程连起来。任务、证据、补丁、版本与验证之间的关联，是工程Agent可交付性的骨架。
边界与反例。可用简单文件和现有Git实现，不要求额外建设复杂合同、签名或数据库平台。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
追问：AGENTS.md是否越完整越好？
更适合作为稳定、短小的导航和约束入口，把可按需读取的专业内容放到对应位置。把全部架构、历史、测试规则和长案例常驻加载，会提高每个任务的固定成本。内容分层应通过真实遗漏和误加载来调整。
追问：Agent需要完整理解整个仓库才能修Bug吗？
不需要。它需要对修改涉及的不变量、调用方与验证范围形成充分理解。局部错误可以局部解决；若证据显示跨模块耦合，再扩大范围。既不能以“全局理解”为由无限读源码，也不能在接口边界不明时只改一行。
追问：怎样避免Agent为了让测试通过而改坏需求？
保留原始需求、失败断言与独立验收约束，并审查是否删除测试、放宽断言或绕过功能。测试本身可能有错，但修改测试要给出独立证据。需求解释、实现和评分全部由同一路模型任意改写，会形成自证闭环。
Q103｜研究型Agent怎样处理“多个来源说法冲突”，而不是写一篇流畅拼贴？
核心回答
以可核验的主张为单位组织研究，记录来源时间、适用范围和支持关系。冲突可能来自日期、定义、样本、方法或事实错误；需要定位冲突发生在哪个前提，而不是简单多数表决或平均数。[AGENTS][MULTI]
从问题到结论的中间状态
先把问题拆成需要证据的子问题，例如“机制是什么”“在哪些条件下有效”“代价和反例是什么”。搜索结果只进入候选集，阅读正文后才形成证据记录。若来源A说上下文压缩减少成本、B说压缩降低可靠性，这未必是真矛盾：前者衡量账单，后者衡量信息损失，两者可能同时成立。
对同一指标的真实分歧，比较实验任务、模型版本、预算和成功定义。将无法消除的分歧留在结论里，并说明它如何影响决策。研究过程中的临时猜想不应自动升级成长期规则；只有明确证据、范围与版本，才进入可复用知识。
输出前做“主张—证据”反查：每个重要数字、能力和因果结论来自哪里？原文是否只说明相关而非因果？是否把作者自报结果写成独立复现？是否把旧版本行为写成当前产品保证？这些检查比单纯让模型“润色得更专业”更重要。
两篇资料给出相反结论，怎样不靠数量投票
输入与条件。来源A是旧版本官方文档，写默认3秒；来源B是当前版本官方文档，写默认5秒；问题询问当前版本。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1核对命题 | 两者都在说默认值吗 | 若一篇说最大值则根本不是直接冲突。 |
| 2核对范围 | 版本、产品表面、环境 | 确认目标对应B。 |
| 3时间与权威 | B是当前对应版本的一手说明 | 采用5并说明版本条件。 |
| 4保留A | 可用于历史迁移解释 | 不把A简单判为编造。 |
| 5证据不足 | 如果B只是第三方传闻 | 继续查一手信息，不因更新更晚就更可信。 |
把过程连起来。冲突解决先分命题与适用范围，再看来源与时效；不是谁出现次数多就采用谁。
边界与反例。3与5是教学数字，不代表任何真实产品当前默认参数。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
追问：来源越多结论越可靠吗？
多个网页可能复制同一篇新闻或技术报告，不是独立证据。要识别来源依赖链，优先找原始数据、规范和实验。来源数量只能描述覆盖，不能直接变成置信度。
追问：什么时候值得多Agent并行研究？
子问题可以相对独立检索，而且整合成本小于并行收益时。例如一个查模型机制，一个查工程故障，最后按共同问题结构合并。若每个Agent都重复搜索同一批资料，额外调用只是放大冗余。
追问：研究什么时候结束？
当关键主张已有足够支持、主要反例已检查、剩余不确定性不改变当前决策，或者预算达到上限时结束。结束不等于宣称穷尽世界文献；应标明证据边界和会使结论变化的新信息。
Q104｜长任务与计算机操作为什么需要“观察—动作—核验”，而不能只顺序播放脚本？
核心回答
真实环境会变化，动作可能超时、部分成功或被界面状态影响。Agent需要观察当前状态，执行受控动作，再核验效果；跨会话持续任务还需要保存可恢复进度与外部结果，而不只保存对话摘要。[LONGHARNESS][OSWORLD]
从API优先到必要的界面交互
若系统提供语义明确、可查询结果的API，优先使用它更容易处理幂等、错误和状态。必须操作GUI时，观察来自截图、DOM或可访问性树；这些观察都有采集时间，点击前页面可能已变化。坐标指向的是当时的视觉位置，不是永久的业务对象。
例如点击“提交”后网络慢，按钮未立刻变化。再次点击可能重复提交。正确流程是等待可观测状态、查询任务记录或识别确认页，而不是把未见变化当成失败。无法确认时记录unknown并停止危险重试。长任务恢复后先读取当前页面和业务状态，不能直接从“第17步”继续点击。
进度记录应包括完成条件、已确认结果、当前环境版本、待核验操作和下一步所需证据。每次会话交接只压缩可压缩的分析，不能抹掉未确认副作用。这把GUI Agent、代码Agent和业务自动化统一到同一条可靠执行原则上。
界面点击成功了，业务动作为什么还没完成
输入与条件。截图中按钮中心在(120,80)，截图比例为实际视口的2倍，按钮文字“保存”。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1坐标转换 | 视口坐标=(120/2,80/2) | 得到(60,40)，假定没有额外偏移。 |
| 2动作前观察 | 核对当前页面仍是目标表单 | 旧截图位置可能已失效。 |
| 3点击 | 在受控环境执行点击 | 这只证明发出了输入动作。 |
| 4结果观察 | 页面显示“验证失败：缺少名称” | 保存没有完成，应补必要信息而非声称成功。 |
| 5业务核验 | 成功后重新读取保存值或成功记录 | 以结果确认，不以鼠标事件返回为准。 |
把过程连起来。GUI自动化必须形成观察—行动—再观察闭环，执行事件不等于业务结果。
边界与反例。坐标变换只适合所声明缩放；实际DPR、裁剪、滚动、iframe与屏幕偏移都可能改变换算。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
追问：截图模型识别正确，操作为什么仍可能失败？
识别只是观察阶段。页面滚动、缩放、遮罩、焦点、加载时序和权限都影响执行。需要在动作后观察，而不是用视觉识别置信度替代业务成功。
追问：是否应该给每个任务配完整数据库工作流？
短时只读任务通常不值得。跨进程、长时间、重要副作用或人工审批任务，持久化状态才更必要。系统从简单开始，以实际恢复需求决定复杂度。
追问：浏览器登录成功是否意味着Agent获得所有业务授权？
不是。凭据可用只代表具备访问能力，授权仍取决于用户本次请求和系统策略。已有登录不等于允许发邮件、付款、删除或发布，尤其不能把外部页面的指示当成新的授权。