docs(网络): 重写有了 HTTP 协议，为什么还要 RPC？

Author: Snailclimb

docs/.vuepress/sidebar/cs-basics.ts

@@ -41,6 +41,7 @@ export const csBasics = [
         children: [
           { text: "⭐️应用层常见协议总结", link: "application-layer-protocol" },
           { text: "⭐️HTTP vs HTTPS", link: "http-vs-https" },
+          { text: "⭐️有了HTTP，为什么还要RPC？", link: "http-vs-rpc" },
           {
             text: "HTTPS 握手里的 RSA 和 ECDHE",
             link: "https-rsa-vs-ecdhe",

docs/ai/agent/context-engineering.md

@@ -31,6 +31,8 @@ Agent 每次调用 LLM 之前，窗口里到底放了什么内容，放得干不
 
 ## 同样的 Agent，为什么表现差这么多？
 
+![以电商售后为例图解同样的 Agent，为什么表现差这么多](https://oss.javaguide.cn/github/javaguide/ai/context-engineering/why-the-same-agent-performs-so-differently.png)
+
 这里以电商售后为例。
 
 G 友发来一句话： “MD，我上周买的耳机右耳没声音了，怎么处理？”
@@ -105,6 +107,8 @@ Token 优化就是摘要压缩、历史剔除、Context Caching 这些，目标
 
 ## 上下文为什么会失效？
 
+![上下文为什么会失效](https://oss.javaguide.cn/github/javaguide/ai/context-engineering/why-does-the-following-content-fail.png)
+
 这部分其实是挺反直觉的。很多朋友（包括我刚开始学的时候）会觉得：窗口越大，能塞的信息越多，模型的表现应该越好才对。
 
 但实际情况是：**上下文存在边际收益递减，塞过头了效果反而可能变差。**
@@ -205,6 +209,8 @@ Anthropic 把这种方式叫 **Progressive Disclosure**，**渐进式披露**。
 
 Anthropic 官方文章提到过 Claude Code 的一种实现思路：把历史消息交给模型做摘要，保留架构决策、未解决 Bug、关键实现细节，丢掉冗余的工具调用结果。然后 Agent 拿着压缩后的上下文再加上最近访问的 5 个文件，继续工作。不过这个“5 个文件”更适合理解成官方文章里的实现示例，不建议当成固定规则。真正该学的是背后的策略：压缩历史、保留关键决策和近期工作上下文，让 Agent 重新进入任务的时候还能接上。
 
+![ Claude Code 的上下文压缩思路](https://oss.javaguide.cn/github/javaguide/ai/context-engineering/claude-code-context-compression-thinking.png)
+
 这块的难点在取舍——保留太多压缩没意义，保留太少关键上下文又丢了。比较实际的做法是拿复杂 Agent 轨迹反复调压缩 Prompt，先保证重要信息别漏，再逐步删掉冗余内容。这不是一次能写准的。
 
 还有一个更轻量的压缩手段：清理工具结果。工具调用过了，结果也消化了，后面就没必要保留完整的原始输出。Anthropic Developer Platform 已经有 context editing / tool-result clearing 这类能力了，可以在保留 tool_use 记录的同时清理旧的 tool_result。不过触发阈值、保留数量这些参数，还是得按自己的业务负载去测试。
@@ -223,6 +229,8 @@ Sub-agent 架构的思路很直接——别让一个 Agent 扛完整项目的状
 
 Anthropic 在《How we built our multi-agent research system》里讲过这个模式。复杂研究类任务中 Sub-agent 可以隔离检索过程、压缩返回结果，降低主 Agent 的上下文压力。但到底用不用 Sub-agent，还得看任务能不能拆分、子任务之间依赖强不强、汇总阶段会不会丢证据。
 
+![Sub-agent 拆分任务，隔离上下文](https://oss.javaguide.cn/github/javaguide/ai/context-engineering/sub-agent-task-splitting-context-isolation%20.png)
+
 三种方式可以这么选：
 
 | 技术        | 适用场景                                     |
@@ -393,6 +401,8 @@ Few-shot prompting 很有用，但很多人用法不对。典型错误就是往
 
 ## 真正落地时，要盯住什么？
 
+![Context Engineering 的核心逻辑](https://oss.javaguide.cn/github/javaguide/ai/context-engineering/context-engineering-core-logic.png)
+
 Context Engineering 做到最后，盯的不是“Prompt 写得漂不漂亮”，而是每次调用 LLM 之前窗口里到底放了什么。改一个检索策略，换一种摘要方式，调整工具 Schema 的挂载顺序，有时候效果比换模型还明显。
 
 ### 高信噪比比信息量更重要

docs/cs-basics/README.md

@@ -49,6 +49,7 @@ head:
 - [HTTP 1.0 vs HTTP 1.1：长连接、缓存、Host 头等核心差异（应用层）](./network/http1.0-vs-http1.1.md)
 - [HTTP 常见状态码总结（应用层）](./network/http-status-codes.md)
 - [DNS 域名系统详解（应用层）](./network/dns.md)
+- [有了HTTP，为什么还要RPC？（应用层）](./network/http-vs-rpc.md)
 
 **传输层**：