Context Engineering
Context Engineering 指南：企业 Agent 为什么不能只靠 Prompt
企业 AI Agent 的质量，往往不是由一个 prompt 决定，而是由上下文供应链决定。
为什么 Prompt 不够？
Prompt 能指导模型怎么回答，但企业现场的问题通常是：模型看不到正确资料、拿不到权限、 不知道当前任务状态，也不知道什么动作需要人工确认。这些不是改一句提示词能解决的。
Context Engineering 包含什么？
- 知识上下文：文档、FAQ、表格、客户记录和历史工单。
- 任务上下文：当前目标、步骤状态、输入输出和验收标准。
- 工具上下文：可调用 API、MCP 工具、权限、速率限制和失败兜底。
- 组织上下文：谁审批、谁接管、谁对结果负责。
FDE 的现场做法
FDE 做上下文工程，应该从真实任务流开始，而不是从模型参数开始。先画出业务流程， 标注每一步需要哪些信息、哪些系统、哪些人工判断，再决定检索、缓存、记忆和工具调用策略。
评测方式
- 缺失上下文时是否能主动提问？
- 冲突上下文时是否能标注不确定性？
- 工具失败时是否能停止并交给人工？
- 输出是否能追溯到来源和任务目标？
继续阅读
常见问题
Context Engineering 和 Prompt Engineering 有什么区别？
Prompt Engineering 主要优化单次提示词；Context Engineering 设计的是模型每次行动前能看到什么信息、调用什么工具、遵守什么边界，以及如何持续更新上下文。
为什么企业 Agent 更需要 Context Engineering？
企业场景里信息分散在文档、数据库、权限系统和业务流程中。没有上下文工程，Agent 很容易看不到关键事实、越权调用工具或无法解释结果。
FDE 应该如何开始做上下文工程？
先梳理业务任务、输入输出、可用知识源、权限边界和失败样本，再设计检索、记忆、工具调用和评测闭环。