在天通苑合租房里，我把上下文工程写进了考公笔记

去年十月底的一个周三晚上，我坐在天通苑12平米的合租次卧里发呆。桌上摊着两样东西：左边是公司让我调研的智能体开发文档，右边是粉笔的行测5000题。那一刻我觉得，自己像极了一个上下文窗口被塞满的模型——白天处理业务需求，晚上灌行测申论，token不够用了。

上下文工程不是新词，但真正理解它，是在我快被信息淹没的时候。

年初我们组接了个智能体项目，做自动处理工单的Agent。我负责Prompt和上下文管理模块。一开始我把用户输入、历史对话、系统指令一股脑全塞进上下文。结果工单场景里用户描述千奇百怪，上下文一会儿爆掉，一会儿又信息不足。最离谱的一次，Agent把“打印机卡纸”理解成“需要更换网络交换机”。

那段时间我天天加班到十点，地铁上都在看LangChain文档。有天晚上给大学室友发微信：“我感觉我在教一个金鱼记忆的实习生干活。”他回我：“这不就是没做上下文工程吗？”

这句话点醒了我。上下文工程的核心不是“把更多信息塞进去”，而是在正确的时间，给模型正确的信息，并且只给这些信息。我开始重构流程：先做意图分类，再根据意图动态裁剪上下文。日志太长就摘要，历史对话只保留关键节点，系统指令按场景分片加载。简单说，就是给模型做“信息节食”。

效果立竿见影。工单分类准确率从71%提到89%，响应时间缩短三分之一。Leader在周会上夸我“有想法”，只有我自己知道，那是我在地铁上、在折叠桌前一行一行调试出来的。

智能体开发教会我的第二件事：别把Agent当函数用。

很多教程把智能体开发讲得像搭积木：工具调用、记忆管理、规划器，拼起来就完事。但真实业务里，Agent最大的问题不是能力不够，而是不确定性。同样一个输入，它可能给你三个不同的执行路径，其中两个是错的。

有次我写了个SQL查询工具给Agent用，它偶尔会把表名搞错。不是模型不认识，而是它在“决定用哪个工具”这一步就判断失误了。我花了两天加校验层、加回退机制，最后发现最有效的办法是：把工具的输入输出格式写死在Prompt里，并且给每个工具配上“什么时候不该用”的反例。

写代码是确定性的，if就是if。但Agent是概率性的，你得像带徒弟一样，不仅要教它怎么做，还要教它什么时候别做。

Stable Diffusion是那段时间唯一的“甜点”。

白天调Agent，晚上刷题刷到脑子发木的时候，我就打开SD跑几张图。说来好笑，我是为了接私活才学的SD，结果它反而成了我的解压方式。戴上耳机、调好参数、点下Generate的那一刻，世界就安静了。看着画面从噪点里一点点浮现，有种在混乱中建立秩序的快感。

SD也让我对“调参”有了新理解。以前觉得调参就是玄学，后来发现它和上下文工程异曲同工：你给模型的条件越精准，它给你的结果就越可控。 提示词太模糊，出的图就千奇百怪；加几个质量词、负面提示、调整采样步数，画面立刻不一样。这跟给Agent设计上下文，本质上是一回事。

说到考公，很多人问我为什么。

原因很朴素：我住在天通苑，每天早上七点半挤5号线去西二旗，晚上九点再挤回来。这样的日子过了三年，我开始想，如果三十五岁还在挤这趟地铁，我受得了吗？答案是否定的。

所以去年十月，我正式把考公提上日程。技术没有放下，因为我知道，解决问题的能力才是真正的护城河。上下文工程、智能体开发、SD调参，本质上都在训练一种能力：在复杂、模糊、信息过载的环境里，找到那条最有效的路径。这跟行测里的资料分析、申论里的材料概括，底层逻辑是相通的。

上周五晚上，我做了一套行测模考，资料分析错了7道。心里挺不是滋味。但转念一想，这跟调Agent遇到bad case有什么区别？定位问题、分析原因、针对性改进，然后下一轮。

技术探索对我来说，从来不是为了炫技。它是我在这个城市里保持清醒和前进的一种方式。不管最后上岸还是继续写代码，这大半年学到的东西，已经长在我身上了。

给看到这里的朋友一句真心话：别把技术当成目的，把它当成你理解世界的透镜。 当你用调试Agent的思路去复盘自己的学习，用设计上下文的思路去规划自己的精力，你会发现，很多东西其实是通的。

而我，还在路上。天通苑的灯还亮着，下一套模考卷子已经打印好了。