参考文档：https://www.langchain.com/blog/context-engineering-for-agents
Context Engineering
Context Engineering 与 Prompt Engineering
说到Context Engineering，或许会让人联想到Prompt Engineering
在早期LLM只是作为聊天对象，因此只有人和机器之间的消息交互。
而随着LLM的应用发展，LLM被接入各种工具，知识库。Prompt概念无法满足对模型输入信息的概括（例如工具调用结果的返回并不是人与机器之间的消息交互），并且由于模型注意力机制以及上下文的限制，Context Engineeing诞生了。
下面的一句话完美概括了Context与Prompt的关系
Prompt 是你对模型说的话；Context 是模型所处的世界。 当模型只是聊天对象时，你说的话就是它的整个世界——所以那时 Prompt = 一切。 当模型成为 Agent 时，它的世界由系统构建：检索来的资料、工具的状态、子 Agent 的隔离、历史的摘要……你说的话，只是这个世界里的一条消息。
深入Context Engineering
为什么需要上下文管理
长时间的任务执行与工具调用，会占用大量上下文，并引发如下问题
- Context Poisoning: When a hallucination makes it into the context
- Context Distraction: When the context overwhelms the training
- Context Confusion: When superfluous context influences the response
- Context Clash: When parts of the context disagree
- 上下文投毒：错误的信息进入了上下文，模型在假信息之上继续推理
- 上下文淹没：信息太多，忘记自己该干什么
- 上下文混淆：无关信息把回答带偏了
- 上下文冲突：上下文内部互相打架
| 病根 | 病灶 | 一句话 | 典型场景 | 防御手段 |
|---|---|---|---|---|
| Poisoning 投毒 | 假（幻觉进入） | 信了假的 | 上下文里有谎话，模型当真 | 子 Agent 幻觉传播、AI 生成的检索源 |
| Distraction 淹没 | 多（量太大） | 忘了该干嘛 | 信息太多，把指令和训练行为淹了 | 超长上下文、整库塞入 |
| Confusion 混淆 | 杂（无关干扰） | 被带偏 | 对的也在，但杂的把它挤偏了 | few-shot 泄漏、相似 API 混入 |
| Clash 冲突 | 矛盾（互相打架） | 不知道信谁 | 上下文内部互相矛盾，模型瞎裁决 | 新旧版本同框、多源矛盾 |
如何进行上下文管理
| Context Engineering 手段 | 防的病 |
|---|---|
| 获取（RAG 质量、来源可信度） | 防 Poisoning |
| 筛选排序（去噪、顺序工程） | 防 Confusion |
| 预算压缩（截断、摘要、缓存） | 防 Distraction |
| 隔离（子 Agent 作用域、优先级） | 防 Clash（+ 防 Poisoning 传播） |
Harness Engineering
Context Engineering解决的事模型输入侧的问题，而Harness Engineering解决的是Agent系统如何安全可靠的运行
对于系统来说需要满足下面几个条件
- 高可靠（持久化，检查点）
- 安全（权限控制）
- 可观测（日志，链路追踪）
- 环境隔离（沙箱化，子代理）
项目阶段中Harness Engineering的应用
- 启动阶段
为避免污染全局环境，需要分配一个沙箱环境 - 编码阶段
模型尝试修改生产环境配置，系统会识别安全便捷，抛出请求 - 高危操作
对于高危的脚本吗/敏感工具调用，系统需要拦截，将选择权交给用户 - 意外中断
每完成一个节点，系统都会持久化保存 - 报错处理
收集全链路Trace，给人/Agent进行排查 - 完成阶段
测试检查
评论（0）
暂无评论