搞Android的怎么可能搞不懂Context Engineering?

熟悉的Context

只要是做Android开发的，都应该对"上下文"这个词不陌生，就是那个随处可见的Context,我们对它太熟悉了，因为如果处理不好它，就有可能导致Activity内存泄漏，也可能为了用它，需要当作参数传递多个函数或类，也可能因为误操作，导致在Application里面存了个Activity，从而引用一堆泄漏问题，而现在我们忽然发现AI Agent里面也有一个上下文，而且处理不好也会导致"内存(token)泄漏",作为多年Android老师傅的你，此时是不是共情了，甚至还会觉得，上下文工程可能就是仿Android来设计的

系统提示 = AndroidManifest.xml

上下文工程核心要素之一的系统提示，知道它的作用是啥吗？如果不知道，可以用Android的角度来思考，系统提示类似于AndroidManifest.xml，有没有人试过一个Android项目如果把AndroidManifest.xml删掉会怎样？其实不用试也知道，肯定跑不起来，AndroidManifest.xml就是用来告诉系统：这个app是什么、有哪些组件、需要什么权限、最低支持什么版本

其实系统提示就是Agent里面的AndroidManifest.xml，一个没有系统提示的Agent同样也是跑不起来的

系统提示写了得有意义

来看下面的提示语

这么短的提示语写出来谁知道具体要干啥，就相当于你写了个AndroidManifest，然后里面只有 <manifest/> 标签，其他啥也没有。系统会一脸懵逼：你谁啊，你要干啥？

真正像样的系统提示

所以这个时候你应该懂了，系统提示就应该按照AndroidManifet那样的模版去写

好的系统提示就像一份完整的AndroidManifest，可以让系统（Agent）看到了就知道你是什么样的app、能干嘛、什么时候该唤醒你

工具定义 = SDK文档 + 接口

有做过sdk开发的一定对写sdk文档不陌生，一个好的sdk文档必须包含清晰的签名、参数说明、返回值、异常都会返什么信息，而工具定义就是给Agent看的sdk文档,工具定义如果写的不好，就像没写注释接口一样，不知道是干啥的

Agent看到这种描述，就像让你看一个没有注释的接口一样，你知道它大概要干嘛，但不知道参数怎么传、什么情况下会挂、返回值长啥样，如果你遇到这种接口，你会怎么用呢？只能瞎用呗，凭感觉调用，参数priority假设只有0跟1有效，结果Agent觉得传5也行，然后传了5之后果断翻车了，所以得说清楚，正确的做法应该是

写工具描述就像写sdk文档一样，你得假设使用你的人（或者 Agent）是个刚入职的实习生，对你们的内部逻辑一无所知，你要把所有信息都要说到位

历史记录压缩 = Logcat 管理 + LeakCanary 分析

在调试Android项目的时候，Logcat里面看日志一定是经常会去观察，但是大家都知道Logcat里面大多数都是些没有用的信息，比如

这类信息对于你解决问题一点帮助也没有，你想要的只有那些error级别的崩溃信息，于是你会过滤一下level,可能还会加点tag,Agent的历史记录也是一样的，如果不压缩历史记录，就跟没加过滤的Logcat一样，每一轮对话、每一个中间结果，全都在上下文里堆着。Agent 每次干活都要翻一遍"不加过滤的Logcat"才能找到有用的信息。

Agent在压缩历史记录上，有四种压缩策略

滑动窗口

方法：保留最近n轮完整记录

适用场景：短对话，实时交互

就像你在处理一个紧急问题，每次都会清一下Logcat,只是这样做的话，你的上下文信息也都丢了

阶梯摘要

方法：每轮做一次增量摘要

适用场景：长对话，客服场景

就像你打release包的时候，给代码做了一次混淆，资源压缩一样，但是不影响功能

分层摘要

方法：近期保留完整、远期做摘要

适用场景：文档生成、复杂任务

这个就跟Android的冷，温，热启动一样

关键轮标记 = 打TAG

方法：标记重要轮次，其余丢弃

适用场景：调试、分步执行任务

这类策略就如同我们给日志分等级一样，不同影响程度的日志分别有不同的level

跟 Logcat 的 VERBOSE / DEBUG / INFO / WARN / ERROR 一个道理,不是所有信息都有同等的价值

检索上下文 = 翻文档，看源码

我们在做需求的时候遇到不会的东西怎么办？（除了问AI），以下四点应该都干过

搜谷歌
先搜官方文档
再搜StackOverflow
看博客
翻源码

一般我们在看源码的时候，肯定不会把sdk所有的源码看一遍，那这样看一天估计都看不完，肯定是去看一些关键的地方，检索上下文也是一样，塞给Agent的知识库也不能一下子全塞给他，应该是按需注入，那么如何注入，如何提高注入的质量呢？

查询改写 = 把你的问题翻译成搜索引擎能懂的语言

当你在搜索引擎里面输入"Activity 传参数"，搜索引擎会翻译成"Activity之间如何传参数"，但你说"这个东西怎么搞"，搜索引擎就一脸问号："你要搞啥？"

Agent也一样，用户说"帮我做个图片加载"，Agent不能直接拿这句话去检索，会先把它改写成技术语言

长度裁剪 = 只看源码里你需要的那个方法

都看过SDK源码吧？比如打开 TextView.java，你会从头读到尾吗？肯定不会，你会cmd+F 搜 setText，只看那一个方法的实现。

检索也要裁剪，不要返回整篇官方文档，只返回跟当前问题直接相关的那几段

回收机制 = 管理Activity里面的资源

通常我们在Activity里面释放资源的位置都会选在onDestroy里面，比如某个页面用了个比较大的Bitmap,那么肯定要在页面销毁的时候释放一下这个Bitmap的资源

Agent的上下文也需要在生命周期阶段完成回收，每一轮调用结束后，上一轮的上下文不会自动消失，它还在那里，占用着"内存"（token），所以如果你不主动管理，就跟不调 onDestroy() 一样，会造成"内存泄漏"

这就像你的app不释放资源一样，最后被系统杀掉，解决方案

所以一个好的上下文必须要有好的回收机制，不然就是一场慢性的OOM

上下文的三大模式

常见的上下文模式分为三种，每一种都能在里面看见Android的影子

模式一：渐进式披露 = App 启动优化

先说下第一种，类似于做App的启动优化，一个比较好的启动流程不会在 Application.onCreate() 里把所有模块都初始化一遍，而是会按需加载、懒加载

给Agent的上下文，也要按需加载

记住给Agent的上下文跟优化启动的思路是一样的，不要一开始就把所有"库"全部都初始化

模式二：上下文压缩链 = View的绘制流程

问一个经典面试题：View的绘制流程主要经过哪三个函数，这个被问烂的题目的答案大家都会脱口而出，onMeasure,onLayout以及onDraw,而这三个函数也刚好可以体现出上下文压缩链的特征，上下文压缩链是这么描述的

当一个任务需要处理大量数据时，用链式调用拆分为多个步骤，每步只保留关键中间结果。每条链路的输入都是上一步精炼后的摘要，而非原始数据，使得上下文始终保持可控大小

关键语句，每条链路的输入就是上一步精炼后的摘要，我们再看下刚才说的View的绘制过程中的三个函数，是不是也有这样的特点

onMeasure--输入：父View的MeasureSpec，输出：每个子View的measuredWidth和measuredHeight
onLayout--输入：上一步输出的尺寸，输出：每个子View的left，top，right，bottom
onDraw--输入：上一步输出的位置信息，输出：Canvas绘制

其中measure阶段不会把屏幕的所有像素数据都传给下一步，只会尺寸的摘要，而Layout阶段不会把整个视图树测量的数据传给下一步，只传位置矩形的四个点的位置，这里就体现出了上下文压缩链精炼摘要的概念，它的思路很简单，不用一股脑堆数据，要逐层压缩、每步只做本层的事，传给下层的永远是够用但不冗余的摘要

模式三：上下文水印 = Android debug调试

上下文水印是啥呢？下面有个例子看下

这个就是上下文水印，在上下文的关键位置放置"水印"标记，帮助监控和诊断Agent行为，这些水印不会直接影响 Agent 行为，但在调试时可以快速定位上下文注入是否按预期执行，那这种东西在Android里面可就太多了

每个文件里面加的TAG，用来过滤日志
配置的BuildConfig，用来配置一些环境信息
用过OkHttp的项目，基本都会加一个HttpLoggingInterceptor，用来看些网络数据
LeakCanary，来排查内存泄漏的原因

在我们项目当中类似的配置可以说出不少，那么这些代码可以不加吗？完全可以，但是有了这些代码后，我们调试工作也方便了很多，这个就是相当于水印对于Agent的作用

评估与迭代 = Crash 监控 + 性能指标

一般我们除了在完成Android日常业务需求之外，也会关注一些线上的一些相关性能数据，这些数据标志着你的app在线上稳不稳定，用户用的体验如何，好比你的app健康不健康，一般会监控的数据如下

崩溃率：Crash-free rate
性能：ANR rate、FPS、启动时间
内存：PSS、GC 次数
包体积：APK size

同样的，上下文的健康好坏也是有一套自己的指标，我们需要按照这些指标不断迭代更新，让上下文的质量越来越好，上下文一般有下面这些指标

优化上下文质量的过程如同优化线上问题一样，同样也是遵循着发现问题 → 优化 → 发布 → 监控 → 再发现问题这样的一个循环

最后

经过这一篇文章的分析，可以发现Context Engineering不仅名字让Android开发看着熟悉，里面涉及到的种种概念也都可以用Android的方式去理解，原本陌生难理解的东西，现在一下子都豁然开朗了