企业官网建设流程全解析

1. 为什么说上下文工程是AI Agent的第二条命

1.1 一个让所有Agent开发者头疼的场景

先说一个我实际踩过的场景。一个负责电商客服的Agent，刚上线的时候表现很惊艳，用户问什么都能答。结果聊到第8轮，用户突然说“我刚才不是说过我的收货地址是XX路XX号吗”，Agent愣了一下，回复“请问您的收货地址是？”——早期对话里的地址信息，已经被后面几轮工具调用结果和闲聊内容彻底挤出了上下文窗口。这个不是模型笨，而是你把“记忆”当成一个永续的东西，可模型明明只长了一个容量有限的“脑仁”。

最气人的是，这还不是最严重的问题。上下文窗口一旦被塞满，模型会开始“选择性失忆”，它不一定是删掉最老的，而是按它的注意力机制捡它觉得重要的。你辛苦设计的System Prompt约束，可能在某次超长工具返回之后就被“冲刷”掉了。整个Agent就从“智能助手”退化成了“人工智障”。我后来把大量时间花在解决这类问题上，才发现所有这些问题都指向同一个领域：上下文工程。

1.2 上下文窗口的本质：有限的工作记忆

用大白话说，大模型每次回答，都只能看到你塞给它的那一整段文本——这段文本就是上下文窗口。它没有真正意义上的“记忆”，只有“眼前这一段”。Agent要完成多步任务，就必须把历史对话、任务目标、工具定义、工具返回结果全部塞进这同一段文本里。问题是，这个窗口看着挺大，实际上非常不经用。

给个具体数字。主流大模型的上下文窗口现在有8K、32K、128K，甚至更大，但注意K是token不是字符。token大约等于一个英文单词的一部分，中文场景下一个汉字大约占0.6到1个token。128K token，看着不小，但你把System Prompt写详细一点、工具Schema放上几个，再塞进几轮多工具调用返回的JSON，很容易就用掉60%以上。真正留给“当前用户问的这个问题”的推理空间，可能只剩20%到30%。如果你还不理解token是什么意思，就把它当成模型处理文本的最小计量单位，一段话会被切分成几百上千个token，模型按token计费，也按token决定自己能“看到”多少内容。

这里要补充一个很多人没意识到的事实：窗口越大，模型注意力越容易被稀释。同样是128K窗口，如果你塞满了几万token的无关日志、冗余工具输出，模型的推理能力会肉眼可见地下降。它不是机器，它像一个记忆力很好但很容易走神的人，信息多了反而抓不住重点。所以“上下文工程”不是抠门地省token，而是把有限的注意力预算，花在真正对当前任务有用的信息上。

1.3 上下文工程和提示词工程不是一回事

很多人第一次听到“上下文工程”时，以为就是换个说法的高级提示词工程。不是。提示词工程关心的是：如何用instruction、few-shot示例、角色设定，让模型更准确地理解任务。上下文工程关心的是：在这个有限窗口里，到底应该放什么、不放什么、先放什么、后放什么，以及当放不下时怎么压缩。

打个比方。提示词工程像你请了一个员工，把规章制度、岗位要求讲清楚，让他知道怎么干活；上下文工程则是你作为管理者，每天给他的工作台上只放今天必须处理的文件，每周把旧文件整理成摘要归档，用得上的档案从抽屉里精准抽出来，而不是把一整年的合同和邮件全堆在桌面上。前者决定“听得懂”，后者决定“干得出”。

所以提示词工程解决的是单轮问答的质量，上下文工程解决的是多轮、多工具、多步骤场景下的系统性问题。你可能会问，谁来写System Prompt？谁来管理历史记录？谁来决定RAG检索结果放进去多少？这些全部属于上下文工程范畴。这也是为什么我常说，想做AI Agent项目，先不要急着调模型，先把上下文工程练熟。

2. 上下文工程的核心环节拆解

2.1 上下文构建：信息放进窗口前的第一道筛选

先来拆第一个环节，构建。每个Agent的每一轮请求，发到模型之前都会拼出一个大的Prompt，我习惯把这段拼装过程叫“上下文构建”。里面通常有四类内容：System Prompt（角色+任务约束）、用户当前输入、对话历史、工具定义和工具返回结果（如果有）。

构建的核心原则，不是“把能拿到的都放进去”，而是“只放当前这一步真正需要的”。我自己有一个底层的习惯：先列清单，再定预算。比如一个工具的Schema描述，如果模型用得到就保留详细描述，如果只是偶尔用一下，就只留名字和必填参数，能省一半token。很多框架封装得太好，开发时你没感觉，一上线发现光工具定义就烧掉了8000 token，这时候再优化就麻烦了。

这里要特别提醒：System Prompt不是写得越长越好。我见过不少团队把公司简介、合规要求、话术规范全塞进去，一上来就占掉4000 token，结果模型反而变“钝”了。好的做法是把固定不变的核心约束放System Prompt，把随任务变化的信息放到当前输入里，把历史里的关键细节抽到“记忆摘要”里，而不是放任所有东西一起挤进去。

2.2 上下文压缩：把旧内容“去粗取精”再装进新窗口

第二环节是压缩。等到对话变长，历史记录会侵蚀剩余窗口。我有三招：滑动窗口、摘要压缩、关键信息抽取。

滑动窗口最简单：保留最近N轮对话，更早直接截断。适合短期任务。但缺点也很明显，早期对话里的关键约束会被无情丢掉，需要用其他机制兜底。

摘要压缩是Agent场景里用得最多的操作。每隔固定轮数或者当token接近阈值，就把旧对话丢给模型“总结成一段记忆”。我一般让模型按固定模板总结，模板里有四个必填项：已完成事项、未完成事项、用户已知偏好、当前关键约束。这样摘要才不会被模型写成“用户问了XX、我回答了XX”这种废话体。

关键信息抽取比摘要更激进，适合工具返回结果特别大的场景。模型调用商品明细接口，返回了2000行数据，其实对当前回答有用的就一个订单状态，那就只保留订单状态。让工具先把返回内容“裁剪”了，把论文级别的JSON压缩成几个要点，再放进上下文中。实测下来，这一步经常能把一次调用从几百token降到几十token。

压缩一定会带来信息损失，所以不要无脑压缩。我自己的经验是：最新的5轮对话永远不压，只压缩更早的对话；系统级别的硬约束每次都重复放一次，哪怕看着冗余，也不能赌模型从摘要里自己推断出这些约束。

2.3 上下文检索：需要的时候再取，不要全塞进去

第三个环节是检索。很多Agent都会接知识库或企业数据，但不能把整个知识库注入上下文，所以得检索。

RAG是最常见的做法：先把文档切块、向量化，用户提问时在主流程外做一次相似度检索，取出Top-K的片段，再注入上下文。关键是Top-K的选择。K太小，信息不够，K太大，噪声大。我在一个客服场景里调过参数：K=3时经常漏信息，K=8时模型被无关片段带偏，最后定在K=5，配合相似度阈值，低于0.75的不取，效果才稳定。这组参数换一个场景肯定要重新调，但至少说明“K不是越大越好”。

第二个容易被大家忽略的是“检索时机”。检索是一次性查完所有，还是在Agent执行过程中按需多次查询？我的实践结论是：不要为了省事在开头把所有相关上下文都拉进来，而是给Agent设计一个search工具，让它在执行过程中发现自己缺信息时主动查。这样能减少大量无效检索。RAG结果本身占据上下文的宝贵位置，你塞进去的块越精准，后面模型推理的富余空间就越大。

2.4 上下文隔离：并发场景下最容易翻车的环节

说到并发，这是上下文工程里最隐蔽但最容易出事的一环。很多人问“ai agent怎么扛并发”，其实第一步不是上K8s、不是扩机器，而是先把状态隔离做对。

上下文隔离是什么意思？就是每个用户的会话上下文必须彼此独立。你想一下：如果多个用户同时用你的Agent，每个人的System Prompt相同没问题，但对话历史、用户画像、工具返回结果完全不同。要是不隔离，用户A就可能在后半段的回复里引用到用户B刚刚说过的信息，这是绝对不能在线上发生的事故。

通常的做法是给每个会话分配一个session_id，并以它为key把上下文存到Redis这类外部存储里。用FastAPI这类异步框架时，每个请求进来，先用session_id从存储里取上下文，处理完再写回去。如果框架本身在进程内维护上下文状态，并发一高，轻则内存爆炸，重则状态串位。我后来观察到的很多“Agent串话”问题，最后追根溯源都是这里出了漏子。

还有一个容易被忽略的点：并发场景下的上下文更新是“读-改-写”三步。如果两个请求同时作用于同一个session，就可能出现丢失更新。要么做请求合并，要么做串型调度，要么加锁，才能真正避免互相覆盖。这不是大模型问题，是标准的并发控制问题，只是很多人第一次用Agent框架时没意识到。

3. 主流Agent架构里的上下文工程实践

3.1 ReAct架构：思考-行动-观察的上下文循环

ReAct这个模式现在仍然是主流Agent架构的基础：模型先输出“Thought”，决定要调用什么工具，然后执行工具，拿到“Observation”，再循环下去。在这个循环里，每一轮产生的Thought、Action、Observation都会被追加到上下文里。一轮ReAct循环，往往要消耗几百到几千个token，动作稍微多一点，上下文就紧张了。

在ReAct架构里，上下文工程的核心矛盾是：观察结果保留多少。有些工具返回结果特别长，我建议在工具本身做裁剪，比如只返回状态、核心数据，不要返回完整原始报文；还有一个技巧是让模型在完成当前子任务后，把那一步的关键结论提炼成一句“结论记录”，而把原始Observation标记为可丢弃。实测下来，上下文长度能少一半，模型效果反而更稳定，因为它不用反复面对令人分心的长文本。

另外注意：很多框架在每轮循环之后都把全部中间变量留在内存里。Agent一多，或者单个Agent跑很长的任务时，这就会直接影响“扛并发”能力。所以我在做工程化时，会尽量保留state里的提炼结果，丢弃原始的繁重中间数据。

3.2 Plan-and-Execute：用计划锚定大局，用局部上下文执行

第二个主流架构是Plan-and-Execute：Agent先做一次计划，列出步骤清单，再逐步执行。这种架构有个隐藏优势，就是上下文工程很好做。

因为计划一旦生成并锚定在上下文里，每一步执行只需要放局部相关的信息，不需要把前面所有执行过程都搬进来。你可以把每一小步的输入、输出单独作为一个“片段”，完成一步就把这一步压缩为“状态更新”，然后读计划继续。这比ReAct的串珠式上下文增长要省很多。

但要注意，Plan-and-Execute的长任务是“计划漂移”的高发区。初始计划在第1步时很合理，执行到第5步时情况变了，模型容易死守旧计划。解决办法是，每隔N步让模型可以根据最新观察修订计划。修订计划时，要把新的约束和新的上下文注入进去，这仍然是上下文工程问题。

3.3 多Agent协作：局部上下文与全局上下文的权衡

到了多Agent框架，情况更复杂。有主Agent调度若干子Agent，也有对等协作的。每一个子Agent都有自己独立的上下文，子Agent返回给主Agent的结果应该是一份“精炼报告”，而不是它的完整会话记录。不然主Agent的窗口会被多个Agent的原始历史一起撑爆。

我见过一种做法：每个子Agent在处理任务时使用自己的上下文窗口，完成之后只返回一个总结文本，包括结论、依据、置信度。主Agent只需要维护全局目标，并把子Agent的总结叠加到自己的计划上下文里。这就把上下文工程从一个窗口的管理，变成了多个窗口之间的“信息抽象与传递”。

有个坑：子Agent的总结如果写得不够好，主Agent就拿不到细节。所以我一般会给子Agent设计一个严格的输出模板，要求带回“结论、证据、风险”。这样全局上下文不仅更短，而且更结构化。

3.4 从架构演进看懂上下文工程的发展脉络

主流Agent架构从最早的ReAct，到Plan-and-Execute，再到AutoGPT那种无限自主循环，再到现在LangGraph这类有状态图框架，其实一路都在解决同一个问题：怎么管理上下文。

早期ReAct实现简单，但上下文爆炸严重；Plan-and-Execute牺牲了一定的灵活性，换来了对上下文的预算控制；AutoGPT类尝试完全自主长期任务，却因为上下文管理失控很快翻车；LangGraph这类图框架把“节点”和“边”显式建模，每一步该带哪些信息，逻辑非常清晰，我接触下来最推荐做工程落地的同学用。像扣子（Coze）这类低代码平台，其实把上下文工程封装成了记忆变量、知识库和全局变量的视觉化操作，适合快速验证原型，但底层逻辑和手写工程仍然一致。

如果你刚开始走ai agent学习路线，我的建议是先把单一上下文的构建、压缩、检索、隔离四个动作练熟，再去玩多Agent。不会单Agent上下文管理就直接上多Agent，大概率会调参调到怀疑人生。

4. 动手实操：用FastAPI+LangChain/LangGraph搭一个上下文可控的Agent

4.1 整体设计：session、state、memory三层分离

现在给一个可以直接参考的最小工程结构。技术栈用FastAPI+LangChain/LangGraph，这也是我个人比较喜欢的组合。先想清楚三层：

第一层是会话层，每个用户一个session_id；第二层是状态层，维护这个session的对话历史、计划、摘要；第三层是记忆层，负责历史的持久化、压缩、检索。这三层分开，后面接并发、接部署都很顺。

LangGraph的好处是可以把状态显式定义成GraphState。GraphState里面我会放四类字段：messages（短期对话历史）、summary（旧对话摘要）、plan（当前计划）、retrieved_docs（本轮检索到的文档）。不要图省事把所有东西一股脑放一个messages里，后面做预算和裁剪会非常痛苦。

用代码表示GraphState长这样：

from typing import Annotated, TypedDict from langgraph.graph.message import add_messages class GraphState(TypedDict): messages: Annotated[list, add_messages] summary: str plan: list retrieved_docs: list

这里有个关键点：messages字段用add_messages注解时，LangGraph会自动做消息追加，让你在多个节点之间传递state时不用手写合并逻辑。但代价是它不会帮你管理长度，所以裁剪逻辑必须自己写在某个节点里。

4.2 核心代码：窗口裁剪、摘要记忆与预算分配

接下来是核心环节。每次进入模型之前，我会调用一个build_context函数，把GraphState转成最终发送给模型的上下文列表。先做个token预算分配，比如总预算8000 token，预留2000给输出，剩下6000里，25%给System Prompt，55%给历史，20%给当前输入和检索结果。这个比例不是拍脑袋，而是我从成本和效果取平衡之后的一个常用初始值。

def build_context(state: GraphState) -> list[dict]: budget_total = 8000 budget_reserve_response = 2000 budget_for_input = budget_total - budget_reserve_response system_text = build_system_prompt() budget_system = int(budget_for_input * 0.25) history = state["messages"] budget_history = int(budget_for_input * 0.55) current_input = state["messages"][-1] budget_latest = budget_for_input - budget_system - budget_history trimmed_history = trim_to_budget(history, budget_history) latest_input = current_input["content"][:budget_latest] return system_text + trimmed_history + latest_input

trim_to_budget是最核心的函数，逻辑是按消息从新到旧地逆序遍历，尽量保留原文，直到token预算用完，超出的旧消息就不再放入窗口。一种做法是只截断最旧的一条，然后把更早的内容替换为摘要：

def trim_to_budget(messages: list, budget: int) -> list: result = [] used = 0 for msg in reversed(messages): tokens = estimate_tokens(msg["content"]) if used + tokens > budget: remaining = budget - used if remaining > 0: # 只对新到旧遍历中遇到的“最后一条旧消息”做截断 trimmed = msg.copy() trimmed["content"] = truncate_to_tokens(msg["content"], remaining) result.append(trimmed) return result[::-1] result.append(msg) used += tokens return result[::-1]

这个实现里有个经验点：estimate_tokens不要用大模型来数token，先用一个快速近似函数，比如字母长度除以4、中文按字数估算，能省一大截延迟；到真正触及预算边界时再用精确tokenizer校验一次。否则每次请求都先调一次模型来“数数”，这是在燃烧成本。

摘要触发逻辑可以设置成“软阈值”：当历史消息的token总量超过预算的80%时，就调用模型做摘要，把最旧的60%的消息压缩进summary字段。伪代码如下：

def maybe_summarize(state: GraphState) -> GraphState: history_token = sum(estimate_tokens(m["content"]) for m in state["messages"]) budget_history_max = 4000 if history_token > budget_history_max * 0.8: old_part = state["messages"][:-4] latest_part = state["messages"][-4:] summary = summarize_messages(old_part, previous_summary=state["summary"]) return GraphState(messages=latest_part, summary=summary, plan=state["plan"]) return state

为什么保留最近4轮不压？因为最近的对话细节对当前回答最有用，宁可牺牲一点历史完整性，也要保住当前交互质量。这个“最近4轮不压”是我自己的经验值，你可以改成5轮、6轮，但核心思路是：摘要只对“不太影响当下回答”的旧内容做，绝不能把刚说完的话也压缩掉，否则用户会觉得你根本没在听。

4.3 部署要点：状态外置与异步接口

代码写完后，得说部署。不少人在本地跑Demo没问题，一到线上就崩，原因往往不是模型选得不对，而是上下文状态没处理好。如果Agent的状态放在进程内存里，多worker部署时，同一个用户的第二个请求可能被另一个worker接住，状态就丢了。

所以我把状态存到Redis，session_id作为key，值是一个JSON序列化后的GraphState。FastAPI接口用async def，每个请求进来先load_state，跑完graph后save_state。一个极简的示意：

from fastapi import FastAPI from redis.asyncio import Redis app = FastAPI() redis_client = Redis.from_url("redis://localhost:6379") @app.post("/agent") async def agent_ep(request: AgentRequest): state = await load_state(request.session_id) final_state = await run_agent(state, request.user_input) await save_state(request.session_id, final_state) return {"reply": final_state["messages"][-1]["content"]}

这样状态就被外置了，Redis的热数据加上淘汰策略，用户的会话可以连续，不至于因为后端扩容就“失忆”。如果你用的是Spring AI这类Java生态方案，同样要明确ConversationId与业务用户ID的映射关系；基于Rust的Agent框架则通常把state的所有权转移作为一等公民，隔离性天然更好，但需要自己动手的部分也多一些。对“ai agent部署”和“ai agent怎么扛并发”这两个问题，我的核心回答就一句话：状态外置，进程不带用户状态。

如果有一天你的Agent延迟卡在Redis的序列化和反序列化上，那再考虑加一层进程内缓存并做好失效兜底，不要一上来就为了性能牺牲状态可靠性。

5. 高并发场景下怎么扛住：上下文工程的成本与性能账

5.1 多用户隔离：session_id是你最后的防线

高并发最常见的故障，不是打挂模型接口，而是把用户上下文搞混串掉。前面说了，session_id是身份的钥匙。但我看到实际代码里容易犯的错是：session_id用了全局唯一ID，但忘了写入上下文存储的key里，或者多个服务实例并发处理同一个session时没有加锁。

如果你用的是Spring AI这类Java生态框架，“会话”往往以ConversationId的概念存在，接入时要搞清楚它和业务用户ID之间的映射关系，不能直接把用户ID当作会话ID——同一个用户同时开两个设备，上下文会互相污染。Rust写的Agent框架很多也强调state的ownership和并发安全，这反而是一个优势，但代价是自己要做的工作更多。

核心就一句话：一切状态操作都要以session_id作为key，读改写三步要保证原子性。并发问题大部分不是出在模型身上，而是出在这把“钥匙”没管好。

5.2 缓存与共享：别让每个请求都重新算一遍

高并发场景下，上下文里其实有大量可复用的内容。例如，同一批工具Schema，所有用户都一样，你可以把它在进程内拼好并缓存，不用每个请求重新序列化一遍。System Prompt如果只是少量用户级变量不同，也可以做模板替换，而不是整段重新生成。

RAG部分也是一样。用户在同一个问题上反复问，向量检索每次都要全量做吗？不必。我通常会做两级缓存：一级是请求级语义缓存，把“问题规范化后的hash”作为key，把召回结果集直接缓存；二级是文档块缓存，同一批高频知识块常驻内存，检索时直接走缓存命中。这几步可以剪掉很大比例的检索耗时。

还要注意一个常被忽略的成本项：token计费是输入和输出分开算的，输出token通常比输入token贵不少，所以别死盯着输入裁剪，输出侧的“废话控制”同样重要。在System Prompt里要求“直接给结论，不要客套话”，实测每次能省几百个输出token，对大并发就是实打实的钱。

5.3 token成本核算：一次真实请求的账单长什么样

光说理论不行，我来算一笔真实的账。假设一家中型SaaS公司，每天有1万个用户请求，每个请求最后发送给模型的输入平均是6000个token，输出平均是800个token。按主流大模型的中等价格水平，输入token单位成本乘以6000，输出token按更高的单价乘以800，再把1万请求乘进去，你会发现一天的成本已经足够让人心疼。

重要的是比例：如果你的上下文工程把平均输入token从6000降到3000，输入成本直接砍半。而输出token如果通过约束减少话痨，从800降到500，总成本能再降一截。这一升一降，叠加每天1万请求的规模，节省的就不是小数目了。很多人觉得上下文工程是为了技术性能，我认为更多是为了商业成本。模型能力再强，你的架构如果每个请求都往里面填一堆冗余内容，这项目也扛不住规模。阿里云的Agent白皮书里也花了很大篇幅讲记忆和上下文的分层管理，底层逻辑是一致的：无论模型多强，最终落地拼的是控制成本、控制延迟、控制上下文。

6. 常见问题与避坑经验

6.1 Agent“失忆”：早期指令被后续对话淹没

这是出现频率最高的问题。Agent聊了十轮之后，忘记了自己最开始的任务约束，开始自由发挥。我排查下来，最常见的不是模型问题，而是早期那几步的System Prompt和其他关键约束没有在上下文裁剪时被保留，被滑动窗口干掉了。

解决办法很简单但反直觉：把最核心的硬约束（比如“不要编造工具不存在的字段”“遇到违规内容必须拒绝”）在每一轮拼上下文时都手动追加一遍，多花几十token，远好过模型事后乱来。上下文工程中，应该优先保证“核心约束的注入频率”，而不是一味追求token节省。

6.2 工具返回内容过大，一次调用就塞爆窗口

之前我一个Agent接了日志查询接口，一次返回能有三万行日志，光一次Observation就直接爆炸。别等模型自己消化，工具端就要做输出裁剪。我当时设计了一个通用的工具响应包装器：所有工具经过它时，先判断内容大小，如果超过阈值，就让一个小模型对返回内容做结构化提取，只保留“结论+关键证据”，原始日志转为附件存储。这样上下文里始终是干净的信息，需要查细节再走一次工具调用。

这个习惯后来被我带到所有项目里。给模型看的工具返回，应该像给领导写的周报，不是把底层代码全贴上去，而是给提炼后的结论。

6.3 RAG召回内容杂乱，反而干扰Agent判断

RAG召回内容多而杂，模型开始引用了不相干的信息。我第一次调这个的时候，把Top-K条结果全塞进去，模型回答“基于文档A（其实是无关文档）”的错误话术。优化方向有三：第一，提高向量检索的相似度阈值，过滤掉置信度低的内容；第二，给每个召回块带上“出处/来源标签”，让模型能判断哪些该优先采信；第三，如果文档本身很长，先做重排，而不是只看向量得分。上下文里放高质量的几块，比塞二十块低质量的要奏效得多。

6.4 串号事故：用户A看到了用户B的上下文

真出过这种事故。用户A投诉说Agent提到了别的用户名，最后发现是Redis的key拼接问题——服务A写的是session:{id}，服务B读的是session{id}，少个冒号，直接串了。

别笑，这种低级问题在并发场景下真的会发生。我的排查经验是：不要只在代码里看，直接在Redis里dump一批运行中的key，核对key规范和value结构；然后给所有上下文读写封装成同一个函数，禁止在业务代码里直接拼key。上线前写一个“并发模拟测试”：同时开20个session、交叉发消息，验证会不会串。

6.5 摘要越抽越薄，Agent行为开始漂移

摘要压缩初期效果好，用久了Agent对用户长期偏好越来越模糊。原因是第一层摘要已经损失了细节，下一次再对摘要做摘要，信息越压越少，最终只剩下骨架。

我的对策是：摘要一定按照结构化模板写，并且保留“关键原文引用”。模板包含：用户目标、已完成子目标、待办事项、偏好与习惯、关键约束。每条偏好后面附带一句原始对话的简短引用，方便在必要时溯源。另外，如果摘要已经做了好几层，就停止继续摘要，直接回退去翻原始对话生成一份新的完整摘要，而不是在摘要上叠摘要。

我一个人把上下文工程从理论到踩坑全走了一遍之后，最大的体会是：这个东西没有银弹，每一套方案都是效果、成本、延迟之间的取舍。比如你会纠结滑动窗口省token但丢信息，纠结摘要模板太死板但能保底，纠结K越大越全面但噪声越大——这些纠结都是正常的，关键是你要有意识和一套工具，把上下文工程当成Agent架构的一部分来看待。

最后顺手分享一个小技巧：每次调完上下文工程的参数，我会把Agent的完整上下文在本地可视化打印出来，用人类视角扫一遍。只要你自己读一遍觉得“这段塞进来没意义”，模型大概率也觉得没用。别再无脑堆信息了，上下文工程本质上就是帮你学会做取舍，这也是AI Agent开发进阶路上最难、最值得啃的一关。