ai-agent-book/chapter10/book-translation/validation/real_20260730T061500Z_v4/judge_receipts/unit-26.json

{
  "schema_version": 1,
  "credential_free": true,
  "attempts": [
    {
      "attempt": 1,
      "request_kind": "quality_judgment",
      "request": {
        "model": "doubao-seed-1-6-250615",
        "messages": [
          {
            "role": "user",
            "content": "You are an exacting bilingual technical-book translation evaluator. Compare two anonymous Chinese translations against the complete English Markdown source. Score both X and Y from 1 to 5 on exactly: accuracy (no omissions, inventions, or changed claims); fluency; terminology (consistent and technically correct); markdown_code_fidelity (figures, links, headings, equations, and fenced code preserved). Each score needs concrete quoted or located evidence. Prefer one only when evidence supports it. Return JSON only: {\"variants\":{\"X\":{\"accuracy\":{\"score\":1,\"evidence\":\"...\"},\"fluency\":{\"score\":1,\"evidence\":\"...\"},\"terminology\":{\"score\":1,\"evidence\":\"...\"},\"markdown_code_fidelity\":{\"score\":1,\"evidence\":\"...\"}},\"Y\":{\"accuracy\":{\"score\":1,\"evidence\":\"...\"},\"fluency\":{\"score\":1,\"evidence\":\"...\"},\"terminology\":{\"score\":1,\"evidence\":\"...\"},\"markdown_code_fidelity\":{\"score\":1,\"evidence\":\"...\"}}},\"preferred\":\"X|Y|tie\",\"preference_evidence\":\"...\"}.\n\nCOMPLETE ENGLISH SOURCE:\nWhat compression most easily loses is not the details themselves, but **early architectural decisions, the reasoning behind constraints, and failed paths**—LLMs typically prioritize deleting information that seems like it could be re-acquired. In production-grade Agent systems, it is recommended to explicitly define retention priorities during compression:\n\n1.  **Architectural Decisions and Key Constraints**: Must not be summarized.\n2.  **List of Modified Files and Key Change Records**: Preserve in full.\n3.  **Verification Status** (pass/fail): Must be retained.\n4.  **Unresolved TODOs and Rollback Notes**: Must be retained.\n5.  **Tool Output**: Can be deleted, retaining only the pass/fail conclusion.\n\nFurthermore, identifiers such as UUIDs (Universally Unique Identifiers), hashes, IP addresses, port numbers, URLs, and filenames must be **preserved exactly as is**—changing even one digit of a PR number or commit hash will cause subsequent tool calls to fail directly.\n\n### Isolation Over Compression: Sub-Agent Context Isolation\n\nCompression removes information *after* it has already entered the context. A more direct approach is to keep bulky intermediate information out of the main context in the first place. This is **Sub-Agent Context Isolation**: the main Agent delegates tasks that generate large amounts of intermediate content, such as \"read a large number of files\" or \"perform a broad search in the codebase,\" to an independent sub-agent. The sub-agent completes the exploration within its own context and returns only a concise summary of a few hundred tokens to the main Agent.\n\nCompare the two approaches for the same task—\"find the function that handles payment callbacks in the codebase.\" If the main Agent searches itself, it might bring dozens of files and tens of thousands of tokens of raw code into the main context. Once the target is found, most of this material remains in the window as permanent noise and must later be removed through compression. However, if delegated to a search sub-agent, the main context only gains two messages: one task description and one conclusion (\"The function is `handle_callback` in `src/payment/callbacks.py`, with two other call sites\")—the tens of thousands of tokens from the intermediate process are discarded along with the sub-agent's context.\n\nThis is essentially **replacing compression with isolation**: compression is a lossy, post-hoc remedy requiring extra LLM calls, while isolation keeps noise out of the main context from the start and leaves the main Agent's KV Cache prefix unaffected. The cost is that the sub-agent does not see the main Agent's full context, so the task description must be self-contained and the goal must be clear. This returns to the chapter's central theme: context sets the capability ceiling, and this holds true for sub-agents as well. Claude Code's Task tool and the retrieval sub-agents used in Deep Research systems are production implementations of this pattern. Chapter 4 discusses the complete design of sub-agents as collaborative tools, and Chapter 10 covers the context architecture of multi-agent systems.\n\n## Chapter Summary\n\nAcross its many technical details, this chapter has one central argument: what you show the model, and how you organize it, matters more to the final outcome than how capable the model itself is. The API's message structure defines the basic structure of the context; the KV Cache constrains what can and cannot be changed; prompt engineering and Agent Skills determine how to efficiently provide static instructions and dynamic knowledge to the model; the Agent Status Bar converts implicit states into directly usable explicit information; and compression strategies address the ever-expanding context problem—not just by controlling length, but by actively summarizing raw data into high-density structured knowledge.\n\nThe common thread among these techniques is explicit, engineered information management: rather than letting the model search passively for clues in a vast context, proactively provide it with refined, structured state. Returning to Rich Sutton's “Bitter Lesson,” general methods that make more effective use of greater compute will ultimately prevail. Every technique presented in this chapter—from KV Cache-friendly context layouts to context-aware compression—is a concrete practice of using engineering to maximize information efficiency at the current boundary of model capability. One distinction must be explicit: this chapter addresses state updates and context degradation **within a single task**. Chapter 8, “Continuous Agent Evolution,” operates on a different timescale: it examines how to evaluate trajectories across tasks and transform their common patterns into persistent updates that change future system versions.\n\nReturning to the Harness framework from Chapter 1, every technique in this chapter operates within its \"Context and Tools\" layer. Together, they determine whether the Agent receives sufficient, refined, and structured information at each decision point. Skills enter the trajectory as tool results through file reading, while compression replaces existing trajectory messages with more concise representations. The Agent Status Bar is unusual only at the API level: because there is no dedicated meta-information role, it uses a `user` message to carry environment state and task progress. Semantically, it supplements the five existing context components rather than creating a sixth. The five-part structure remains unchanged; this chapter adds the engineering detail.\n\nThe next chapter moves beyond information management within a single context window to persistent knowledge systems that span sessions: user memory and knowledge bases. These systems allow the Agent to accumulate experience over time and gradually become a domain expert.\n\n## Thought Questions\n\n1.  ★★★ Experiment 2-3 found that a sliding window of conversation history causes the Agent to repeatedly execute the same tool calls. However, keeping the full history causes the context to expand indefinitely. Design a strategy that can avoid information loss while controlling context length, without breaking the KV Cache prefix.\n2.  ★★ Qwen3's Chat Template chain-of-thought retention mechanism only retains the reasoning content \"after the last real user message.\" If a ReAct loop spans hundreds of tool calls, the accumulated reasoning content can consume a large amount of context. How would you modify this mechanism to handle very long loops? DeepSeek R1 once required stripping all historical reasoning content, while DeepSeek V4 reversed this to mandate passing back all `reasoning_content`—comparing these two opposite strategies, what are the pros and cons of each? What does this reversal indicate?\n3.  ★★ In the context-aware compression experiment, compressing from approximately 148K characters to about 2,000 characters—does this extreme compression risk \"irreversible information loss\"? How can this be addressed?\n4.  ★★ The Agent Status Bar makes implicit states explicit. However, if the status bar itself contains erroneous information (e.g., a bug in the tool counter), the Agent might make harmful decisions based on incorrect information. How can this \"meta-information reliability\" problem be mitigated?\n5.  ★★ The prompt engineering ablation experiment shows that disorganized information leads to a success rate drop of over 30%. However, in real-world development, system prompts are often maintained by multiple people at different times. What engineering practices would you use to prevent system prompts from becoming increasingly disorganized over time?\n6.  ★★★ This chapter proposes that \"in-context learning is essentially retrieval, not reasoning.\" If this assertion holds, all current optimization directions based on \"placing more information into the context\" need to be re-evaluated. How do you think this limitation should be overcome?\n7.  ★★★ Skills' progressive disclosure only loads the full content when the Agent judges it is needed. However, this judgment itself relies on the model's capability—if the model does not know what it does not know, it cannot correctly trigger the loading of a Skill. How can this \"metacognition\" problem be solved?\n8.  ★★ In the Skills mechanism, after the Agent dynamically loads instructions from `SKILL.md`, can subsequent operations reliably follow them? What are the differences in model support for the Skills pattern?\n9.  ★★★ This chapter emphasizes that changes in dynamic information (e.g., system timestamps, tool list order) can break KV Cache prefix hits. In a production system with a large number of tools and a frequently changing tool set, how would you design the context layout to maximize cache hit rate?\n\n\nANONYMOUS CHINESE X:\n### 上下文工程[第17/17部分]\n压缩最容易丢失的不是细节本身，而是**早期架构决策、约束背后的推理和失败路径**——大语言模型通常优先删除看似可以重新获取的信息。在生产级代理系统中，建议在压缩时明确定义保留优先级：\n\n1.  **架构决策和关键约束**：不得总结。\n2.  **修改文件列表和关键变更记录**：完整保留。\n3.  **验证状态**（通过/失败）：必须保留。\n4.  **未解决的待办事项和回滚笔记**：必须保留。\n5.  **工具输出**：可以删除，仅保留通过/失败结论。\n\n此外，UUID（通用唯一标识符）、哈希、IP地址、端口号、URL和文件名等标识符必须**完全按原样保留**——更改PR号或提交哈希的哪怕一个数字都会导致后续工具调用直接失败。\n\n### 隔离优于压缩：子代理上下文隔离\n压缩是在信息已经进入上下文后删除它。更直接的方法是首先将大量中间信息排除在主上下文中。这就是**子代理上下文隔离**：主代理将生成大量中间内容的任务（例如“读取大量文件”或“在代码库中进行广泛搜索”）委托给独立的子代理。子代理在其自己的上下文中完成探索，仅向主代理返回几百标记的简洁摘要。\n\n比较同一任务的两种方法——“在代码库中找到处理支付回调的函数”。如果主代理自行搜索，它可能将数十个文件和数万标记的原始代码带入主上下文。一旦找到目标，大部分这些材料作为永久噪声保留在窗口中，之后必须通过压缩删除。然而，如果委托给搜索子代理，主上下文仅获得两条消息：一个任务描述和一个结论（“函数是`src/payment/callbacks.py`中的`handle_callback`，还有另外两个调用点”）——中间过程的数万标记随子代理的上下文被丢弃。\n\n这本质上是**用隔离代替压缩**：压缩是一种有损的事后补救，需要额外的大语言模型调用，而隔离从一开始就将噪声排除在主上下文之外，且不影响主代理的KV缓存前缀。成本是子代理看不到主代理的完整上下文，因此任务描述必须自包含且目标必须明确。这回到本章的核心主题：上下文设定能力上限，对子代理也同样适用。Claude Code的任务工具和Deep Research系统中使用的检索子代理是这种模式的生产实现。第4章讨论子代理作为协作工具的完整设计，第10章涵盖多代理系统的上下文架构。\n\n## 章节总结\n在众多技术细节中，本章有一个核心论点：你向模型展示什么以及如何组织它，比模型本身的能力对最终结果的影响更大。API的消息结构定义了上下文的基本结构；KV缓存约束了什么可以改变和什么不可以改变；提示工程和代理技能决定了如何高效地向模型提供静态指令和动态知识；代理状态栏将隐含状态转换为可直接使用的显式信息；压缩策略解决了上下文不断扩展的问题——不仅通过控制长度，还通过主动将原始数据总结为高密度结构化知识。\n\n这些技术的共同线索是显式的、工程化的信息管理：不是让模型被动地在广阔的上下文中搜索线索，而是主动向它提供精炼的、结构化的状态。回到里奇·萨顿的“苦涩的教训”，更有效地利用更多计算的通用方法最终会占上风。本章介绍的每种技术——从对KV缓存友好的上下文布局到上下文感知压缩——都是利用工程在当前模型能力边界内最大化信息效率的具体实践。必须明确一个区别：本章解决的是**单个任务内**的状态更新和上下文退化问题。第8章“持续代理演进”在不同的时间尺度上运作：它检查如何跨任务评估轨迹并将其共同模式转化为改变未来系统版本的持久更新。\n\n回到第1章的框架，本章中的每种技术都在其“上下文和工具”层内运作。它们共同决定了代理在每个决策点是否接收到足够的、精炼的和结构化的信息。技能通过文件读取作为工具结果进入轨迹，而压缩用更简洁的表示替换现有的轨迹消息。代理状态栏仅在API级别不同寻常：由于没有专用的元信息角色，它使用`user`消息来携带环境状态和任务进度。从语义上讲，它补充了现有的五个上下文组件，而不是创建第六个。五部分结构保持不变；本章添加了工程细节。\n\n下一章将超越单个上下文窗口内的信息管理，转向跨会话的持久知识系统：用户记忆和知识库。这些系统允许代理随时间积累经验，逐渐成为领域专家。\n\n## 思考问题\n\n1.  ★★★ 实验2-3发现对话历史的滑动窗口导致代理反复执行相同的工具调用。然而，保留完整历史会导致上下文无限扩展。设计一种策略，在不破坏KV缓存前缀的情况下，避免信息丢失同时控制上下文长度。\n2.  ★★ Qwen3的聊天模板思维链保留机制仅保留“最后一个真实用户消息之后”的推理内容。如果ReAct循环跨越数百次工具调用，累积的推理内容可能消耗大量上下文。你将如何修改该机制以处理非常长的循环？DeepSeek R1曾要求剥离所有历史推理内容，而DeepSeek V4反转此策略，强制传递回所有`reasoning_content`——比较这两种相反策略，各自的优缺点是什么？这种反转表明了什么？\n3.  ★★ 在上下文感知压缩实验中，从约14.8万个字符压缩到约2000个字符——这种极端压缩是否有“不可逆转的信息丢失”风险？如何解决这个问题？\n4.  ★★ 代理状态栏将隐含状态显式化。然而，如果状态栏本身包含错误信息（例如工具计数器中的错误），代理可能基于错误信息做出有害决策。如何缓解这个“元信息可靠性”问题？\n5.  ★★ 提示工程消融实验表明，无序信息导致成功率下降超过30%。然而，在实际开发中，系统提示通常由不同时间的多人维护。你将使用什么工程实践来防止系统提示随时间变得越来越无序？\n6.  ★★★ 本章提出“上下文中学习本质上是检索，而非推理”。如果这个断言成立，所有基于“向上下文中放置更多信息”的当前优化方向都需要重新评估。你认为应该如何克服这个限制？\n7.  ★★★ 技能的渐进披露仅在代理判断需要时加载完整内容。然而，这种判断本身依赖于模型的能力——如果模型不知道它不知道什么，它就无法正确触发技能的加载。如何解决这个“元认知”问题？\n8.  ★★ 在技能机制中，代理动态加载`SKILL.md`中的指令后，后续操作能否可靠地遵循它们？模型对技能模式的支持有何不同？\n9.  ★★★ 本章强调动态信息的变化（例如系统时间、工具列表顺序）会破坏KV缓存前缀命中。在具有大量工具且工具集频繁变化的生产系统中，你将如何设计上下文布局以最大化缓存命中率？\n\nANONYMOUS CHINESE Y:\n### 上下文工程[第17/17部分]\n\n压缩最容易丢失的不是细节本身，而是**早期的架构决策、约束背后的推理以及失败的路径**——大语言模型通常优先删除那些看起来可以重新获取的信息。在生产级的智能体（Agent）系统中，建议在压缩时明确定义保留优先级：\n\n1. **架构决策和关键约束**：不得总结。\n2. **修改文件列表和关键变更记录**：完整保留。\n3. **验证状态**（通过/失败）：必须保留。\n4. **未解决的待办事项和回滚说明**：必须保留。\n5. **工具输出**：可以删除，仅保留通过/失败结论。\n\n此外，UUID（通用唯一标识符）、哈希、IP地址、端口号、URL和文件名等标识符必须**完全按原样保留**——即使PR编号或提交哈希中的一个数字改变，也会直接导致后续工具调用失败。\n\n### 隔离优于压缩：子智能体上下文隔离\n\n压缩是在信息已经进入上下文之后进行的。更直接的方法是从一开始就将大量的中间信息排除在主上下文中。这就是**子智能体上下文隔离**：主智能体将生成大量中间内容的任务，如“读取大量文件”或“在代码库中进行广泛搜索”，委托给独立的子智能体。子智能体在其自身上下文中完成探索，仅向主智能体返回几百词元的简洁总结。\n\n比较同一任务的两种方法——“在代码库中找到处理支付回调的函数”。如果主智能体自己搜索，可能会将几十个文件和数万词元的原始代码带入主上下文。一旦找到目标，大部分这些材料会作为永久噪声留在窗口中，之后必须通过压缩移除。然而，如果委托给搜索子智能体，主上下文仅获得两条消息：一个任务描述和一个结论（“函数是`src/payment/callbacks.py`中的`handle_callback`，还有另外两个调用点”）——中间过程的数万词元与子智能体的上下文一起被丢弃。\n\n这本质上是**用隔离代替压缩**：压缩是一种有损的事后补救措施，需要额外的大语言模型调用，而隔离从一开始就将噪声排除在主上下文之外，且不影响主智能体的键值缓存（KV Cache）前缀。代价是子智能体看不到主智能体的完整上下文，因此任务描述必须自含且目标必须明确。这回到了本章的核心主题：上下文设定能力上限，对子智能体也同样适用。Claude Code的任务工具和深度研究系统中使用的检索子智能体是这种模式的生产实现。第4章讨论子智能体作为协作工具的完整设计，第10章涵盖多智能体系统的上下文架构。\n\n## 章节总结\n\n在众多技术细节中，本章有一个核心论点：你向模型展示的内容以及组织方式，比模型本身的能力对最终结果的影响更大。API的消息结构定义了上下文的基本结构；键值缓存（KV Cache）限制了哪些可以改变、哪些不能改变；提示工程（Prompt Engineering）和技能（Skill）决定了如何高效地向模型提供静态指令和动态知识；智能体状态栏（Agent Status Bar）将隐式状态转换为可直接使用的显式信息；而压缩策略解决了不断扩大的上下文问题——不仅通过控制长度，还通过主动将原始数据总结为高密度结构化知识。\n\n这些技术的共同主线是明确的、经过设计的信息管理：不是让模型被动地在庞大的上下文中寻找线索，而是主动为其提供精炼的、结构化的状态。回到里奇·萨顿的“苦涩教训”，更有效地利用更多计算的通用方法最终会胜出。本章介绍的每一种技术——从对KV Cache友好的上下文布局到上下文感知的压缩——都是在当前模型能力边界内通过工程手段最大化信息效率的具体实践。必须明确的一点是：本章讨论的是单个任务内的状态更新和上下文退化。第8章“持续的智能体进化”涉及不同的时间尺度：它研究如何评估跨任务的轨迹，并将其共同模式转化为改变未来系统版本的持久更新。\n\n回到第1章的框架，本章中的每一种技术都在其“上下文和工具”层内运作。它们共同决定了智能体在每个决策点是否获得足够的、精炼的和结构化的信息。技能通过文件读取作为工具结果进入轨迹，而压缩用更简洁的表示替换现有的轨迹消息。智能体状态栏仅在API层面不同：由于没有专门的元信息角色，它使用`user`消息来携带环境状态和任务进度。从语义上讲，它补充了现有的五个上下文组件，而不是创建第六个。五部分结构保持不变；本章添加了工程细节。\n\n下一章将超越单个上下文窗口内的信息管理，进入跨越会话的持久知识系统：用户记忆和知识库。这些系统允许智能体随时间积累经验，逐渐成为领域专家。\n\n## 思考问题\n\n1. ★★★ 实验2-3发现，对话历史的滑动窗口会导致智能体重复执行相同的工具调用。然而，保留完整历史会导致上下文无限膨胀。设计一种策略，在不破坏键值缓存前缀的情况下，避免信息丢失并控制上下文长度。\n2. ★★ 通义千问3的聊天模板思维链保留机制仅保留“最后一个真实用户消息之后”的推理内容。如果ReAct循环跨越数百次工具调用，累积的推理内容会消耗大量上下文。如何修改该机制以处理非常长的循环？深度求索R1曾要求剥离所有历史推理内容，而深度求索V4则反转这一做法，强制传回所有`reasoning_content`——比较这两种相反策略的优缺点，这种反转表明了什么？\n3. ★★ 在上下文感知压缩实验中，从约14.8万字压缩到约2000字——这种极端压缩是否有“不可逆转的信息丢失”风险？如何解决？\n4. ★★ 智能体状态栏将隐式状态显式化。然而，如果状态栏本身包含错误信息（例如工具计数器中的错误），智能体可能会基于错误信息做出有害决策。如何缓解这种“元信息可靠性”问题？\n5. ★★ 提示工程消融实验表明，无序信息会导致成功率下降超过30%。然而在实际开发中，系统提示通常由不同时间的多人维护。你会使用哪些工程实践来防止系统提示随时间变得越来越无序？\n6. ★★★ 本章提出“上下文学习本质上是检索，而非推理”。如果这一断言成立，所有基于“将更多信息放入上下文”的当前优化方向都需要重新评估。你认为应如何克服这一限制？\n7. ★★★ 技能的渐进式披露仅在智能体判断需要时加载完整内容。然而，这种判断本身依赖于模型的能力——如果模型不知道自己不知道什么，就无法正确触发技能的加载。如何解决这种“元认知”问题？\n8. ★★ 在技能机制中，智能体动态加载`SKILL.md`中的指令后，后续操作能否可靠地遵循它们？模型对技能模式的支持有何差异？\n9. ★★★ 本章强调动态信息（例如系统时间戳、工具列表顺序）的变化会破坏键值缓存前缀命中。在具有大量工具且工具集频繁变化的生产系统中，如何设计上下文布局以最大化缓存命中率？"
          }
        ],
        "temperature": 0,
        "response_format": {
          "type": "json_object"
        },
        "extra_body": {
          "thinking": {
            "type": "disabled"
          }
        }
      },
      "response": {
        "id": "0217853911301733b2c90331db17702ff1ef9ef62383e60d62e48",
        "model": "doubao-seed-1-6-250615",
        "created": 1785391142,
        "content": "{\"variants\":{\"X\":{\"accuracy\":{\"score\":5,\"evidence\":\"All key technical claims are preserved, e.g., '上下文设定能力上限' (context sets the capability ceiling) and '用隔离代替压缩' (replacing compression with isolation) are accurately translated without omissions or inventions.\"},\"fluency\":{\"score\":4,\"evidence\":\"Most sentences are fluent, but '大语言模型' (LLM) is not consistently expanded as '大型语言模型' for readability; e.g., '需要额外的大语言模型调用' could be smoother as '需要额外的大型语言模型调用'.\"},\"terminology\":{\"score\":4,\"evidence\":\"Technical terms like 'KV缓存' (KV Cache) and '子代理' (sub-agent) are consistent, but 'Agent' is untranslated in headings (e.g., '子代理上下文隔离') while Y uses '智能体' (intelligent agent), creating inconsistency.\"},\"markdown_code_fidelity\":{\"score\":5,\"evidence\":\"Headings (###, ##), code blocks (e.g., `handle_callback`), lists, and equations are preserved exactly as in the source.\"}},\"Y\":{\"accuracy\":{\"score\":5,\"evidence\":\"Core arguments such as '上下文设定能力上限' (context sets the capability ceiling) and '用隔离代替压缩' (replacing compression with isolation) are fully retained with no distortions.\"},\"fluency\":{\"score\":5,\"evidence\":\"Sentences flow naturally with expanded terms for clarity, e.g., '键值缓存（KV Cache）' and '提示工程（Prompt Engineering）' improve readability without altering meaning.\"},\"terminology\":{\"score\":5,\"evidence\":\"Consistent translation of 'Agent' as '智能体' (intelligent agent) throughout, and technical terms like 'KV缓存' (KV Cache) and '元认知' (metacognition) are uniformly applied.\"},\"markdown_code_fidelity\":{\"score\":5,\"evidence\":\"Markdown elements including headings, code snippets (e.g., `src/payment/callbacks.py`), lists, and bold text are perfectly preserved.\"}}},\"preferred\":\"Y\",\"preference_evidence\":\"Y demonstrates superior fluency through expanded term clarifications (e.g., '键值缓存（KV Cache）') and consistent terminology ('智能体' for 'Agent'), enhancing readability while maintaining full accuracy and markdown fidelity. X's inconsistent 'Agent' translation and less expanded technical terms slightly reduce clarity.\"}",
        "usage": {
          "prompt_tokens": 5226,
          "completion_tokens": 514,
          "total_tokens": 5740
        }
      },
      "latency_milliseconds": 12786,
      "validation": {
        "valid": true
      }
    }
  ]
}