Prompt Engineering 没有过时；它仍负责把指令写清楚。但 Agent 的成败还取决于每轮提供哪些工具、资料、状态、历史与记忆。管理这整组可见资讯，才是 Context Engineering（上下文工程）的工作。
Prompt 是指令，Context 是模型当下看见的世界
Anthropic 在 2025 年的官方工程文章中，把 Context Engineering 描述为 Prompt Engineering 的自然延伸：除了 prompt，也要策划推论时进入 context window 的 system instructions、工具、MCP、外部资料与讯息历史。Anthropic：Effective context engineering for AI agents
可以把两者分成：
| 层次 | 核心问题 | 例子 |
|---|---|---|
| Prompt Engineering | 要模型怎么做？ | 「先列假设，再提供 SQL」 |
| Context Engineering | 模型这一轮需要看见什么？ | schema、指标定义、可用工具、Plan 状态、最近查询 |
好 prompt 放在错 context 里仍会失败。例如指令写着「沿用已核准口径」，但模型根本没看到核准版 Plan；或工具 schema 还提供写入能力，状态却只是唯读探索。问题不在措辞，而在模型所见世界与真实工作环境不一致。
同一句「分析转化率」，有无 context 差多少
只有 prompt
请分析本月转化率下降原因，提供结论与建议。
模型必须猜测资料表、漏斗 stage、分母、时区与输出格式。即使回答流畅，也很可能把通用做法当成公司的实际定义。
有结构化 context
状态：PlanPlanning，不得正式执行
资料：events(event_time, user_id, session_id, event_name)
指标：checkout conversion = paid sessions / checkout_started sessions
时间：Asia/Taipei，完整日，截至 2026-06-30
排除：employee、test、full_refund
Plan：尚有一则 open annotation，要求确认跨日付款窗
可用工具：读 schema、验证查询、修订 Plan
第二种 context 不保证结论正确，但把模型的选择空间缩到可审阅范围：它知道现在不能正式跑、哪个定义有效，以及还缺哪个人类决策。
Agent Context 的六个组件
- Instructions： 角色、品质标准与禁止事项。
- State： 任务在探索、规划、执行或交付哪一阶段。
- Tools： 当轮能读什么、写什么、如何回传结果。
- Data： schema、文件、查询结果与错误讯息。
- History： 最近决策、工具轨迹与尚未解决的问题。
- Memory： 跨对话仍有效、且经治理的规则或业务知识。
设计时不要问「最多能塞多少」，而要问「最小哪组高讯号资讯足以做对下一步」。Anthropic 将 context 视为有限资源，主张找出能提高目标行为机率的最小高讯号 token 集合。这不代表 context 越短越好，而是每个 token 都要有任务价值。
三个常见反模式
把整个工作区每轮重送
好处是「可能都在里面」，代价是 token 成本、旧内容污染与重要资讯被淹没。更好的做法是小型 Summary 常驻，完整 schema 或文件按需读取。
把权限只写在 prompt
「请不要修改资料」若只是文字提醒，模型或工具整合错误时仍可能越界。权限应在工具白名单、唯读查询层与人工授权共同落实；prompt 是一层，不是唯一防线。
把所有对话当长期记忆
对话包含暂时假设、错误尝试与敏感内容。真正跨任务的 Memory 应有来源、生命周期与核准流程，而不是自动把每句话永久注入。
Lantide Data 如何配置分析 Context
Lantide Data 采 Summary／Detail 分层：每轮提供精简工作区、专案、active tab 与快取摘要；需要完整 schema、Plan、Report 或 Reference 时，再由工具按需取得。System prompt 依 NoProject、Planning、Executing 等状态组装，当轮工具 schemas 也随状态过滤。详细设计可见Prompt 与 Context 工程及Agent runtime 架构。
对分析而言，这能让同一句需求同时看见 Plan 状态、查询环境、最近步骤与已核准知识；Queued Knowledge 在使用者 Apply 前不会注入。优点是 Context 与 IDE 真实状态对齐，而不是依赖一条愈来愈长的聊天。
边界同样明确：Context Engineering 只能改善模型取得与使用资讯的条件，不能保证模型推理正确，也不能替代资料品质、Plan 审阅或 Execute 授权。若 schema 本身错、指标定义彼此冲突，系统仍需要人处理。
结语
Prompt Engineering 没有退场，只是从主角变成 Context 系统的一部分。建置或评估 Agent 时，除了看 prompt 模板，也要检查状态、工具、资料、历史与 Memory 如何进入每一轮；真正的分水岭，是模型是否在正确时刻看见正确世界。