企业级 AI Agent 的成本，通常不只取决于调用了哪个模型。随着 Agent 接入企业知识库、外部工具和长期记忆，检索内容过多、工具选择不准、历史上下文膨胀以及重复推理，都会持续推高 token 消耗和响应延迟。
上下文工程的核心，是让 Agent 在每一步只获得完成当前任务所必需的信息。Microsoft Foundry 相关实践将成本优化延伸到知识检索、工具选择、记忆管理和整体 Agent 性能，而不只是简单地切换模型。
成本到底花在哪里
一个企业 Agent 的单次请求成本，可以粗略拆成四部分：
- 输入上下文：系统提示词、用户问题、检索结果、工具说明和历史对话。
- 输出内容：模型生成的答案、计划和工具调用参数。
- 工具执行：搜索、数据库查询、业务 API 或人工审批流程。
- 重复推理：低质量检索、错误工具选择和无效重试带来的额外调用。
在很多系统里，输入上下文会随着工具数量和历史消息增长。模型本身可能没有变化，但每次请求携带的内容越来越多，最终让 token 成本和延迟一起上升。
因此，单纯把所有请求换成更便宜的模型，可能只是降低了单位价格，却没有解决无效上下文和无效调用的问题。
上下文工程的四个抓手
让知识检索返回更少但更相关的内容
知识库检索不应把整个文档或大量低相关片段塞进提示词。可以通过元数据过滤、查询改写、结果重排、去重和上下文压缩，减少传给模型的文本量。
例如，财务 Agent 处理“本季度差旅报销上限”时，检索条件可以包含部门、地区、政策版本和生效日期。这样比在全量制度文档中返回几十个片段更经济，也更容易得到稳定答案。
只暴露当前任务需要的工具
工具描述本身也是上下文。一个 Agent 如果同时看到数十个业务 API 的名称、参数和示例，模型需要花更多 token 进行决策，也更容易选错工具。
可以根据用户意图动态加载工具：查询订单时提供订单查询和物流查询；修改收货地址时才提供地址更新工具。工具路由层还应设置权限、参数校验和超时，避免模型通过反复尝试来“探索”接口。
让记忆服务于任务，而不是堆积历史
长期记忆不等于完整保留所有对话。适合持久化的内容通常包括用户偏好、已确认事实、业务约束和任务状态；临时闲聊、重复问答以及已经失效的信息应被压缩、过期或删除。
一个实用的记忆策略是区分：
- 工作记忆：当前任务必须保留的上下文。
- 用户记忆：跨会话仍然有效的偏好和事实。
- 任务记忆：订单号、审批状态、已完成步骤等结构化状态。
这样可以避免每次请求都重新发送完整会话记录。
用性能指标约束 Agent 行为
成本优化不能只看每次请求的 token 数。更有价值的指标包括：
- 每个已解决任务的平均成本。
- 首次调用成功率和工具调用成功率。
- 平均检索片段数与输入 token 数。
- 无效重试率、最大循环次数和超时率。
- 任务完成率、人工接管率和用户满意度。
如果压缩上下文后成本下降，但任务完成率也明显下降，这并不是优化成功。企业场景需要在成本、质量、延迟和可靠性之间设定可观测的预算边界。
一个可改造的成本估算示例
下面的 Python 示例不依赖外部服务，用来比较“全量上下文”和“经过筛选的上下文”对单次请求成本的影响。示例中的价格是假设值，接入实际模型时应替换为供应商公布的单价。
from dataclasses import dataclass
@dataclass
class Context:
system_tokens: int
history_tokens: int
retrieved_tokens: int
tool_schema_tokens: int
output_tokens: int
@property
def input_tokens(self) -> int:
return (
self.system_tokens
+ self.history_tokens
+ self.retrieved_tokens
+ self.tool_schema_tokens
)
def estimate_cost(context: Context, input_price_per_million: float,
output_price_per_million: float) -> float:
input_cost = context.input_tokens / 1_000_000 * input_price_per_million
output_cost = context.output_tokens / 1_000_000 * output_price_per_million
return input_cost + output_cost
full_context = Context(
system_tokens=1800,
history_tokens=6000,
retrieved_tokens=12000,
tool_schema_tokens=5000,
output_tokens=1200,
)
engineered_context = Context(
system_tokens=1200,
history_tokens=1800,
retrieved_tokens=3500,
tool_schema_tokens=1200,
output_tokens=900,
)
input_price = 2.0 # 假设：每百万输入 token 的价格
output_price = 8.0 # 假设：每百万输出 token 的价格
for name, context in [
("full", full_context),
("engineered", engineered_context),
]:
cost = estimate_cost(context, input_price, output_price)
print(
f"{name}: input={context.input_tokens:,} tokens, "
f"total={context.input_tokens + context.output_tokens:,} tokens, "
f"cost=${cost:.5f}"
)
可以把这个小工具接到离线评测或日志分析任务中，再增加检索命中率、工具成功率和任务完成率字段。成本优化的目标不是盲目追求最小上下文，而是在相同质量目标下，减少无效 token 和无效调用。
在 Microsoft Foundry 中落地时的思路
具体配置会取决于 Agent 架构和使用的模型，但可以围绕以下流程设计：
- 记录每次请求的输入、输出、检索片段、工具调用、重试次数和最终结果。
- 对高频任务建立代表性评测集，记录质量、延迟和成本基线。
- 优化检索策略，限制返回数量，过滤过期内容，并对重复片段去重。
- 按任务动态选择工具，减少默认加载的工具定义。
- 将对话历史压缩为结构化摘要，把长期事实与临时消息分开存储。
- 为 Agent 设置最大循环次数、单任务预算、工具超时和失败转人工策略。
- 用线上指标验证优化结果，防止成本下降伴随答案质量恶化。
Microsoft Foundry 适合承载这类面向企业的 Agent 开发、评测和运营工作。真正重要的不是某一个参数，而是能否把上下文决策、模型调用和业务结果放在同一套观测体系里分析。
采用前的检查清单
- 是否知道一次请求中各类上下文分别占用了多少 token？
- 检索结果是否经过相关性过滤、重排和去重？
- Agent 是否默认加载了并非当前任务所需的工具？
- 历史对话是否有摘要、过期和容量限制？
- 是否区分了模型调用失败、工具失败和业务失败？
- 是否同时监控任务完成率、人工接管率、延迟和单位任务成本？
- 是否为循环调用、重试和高成本任务配置预算上限？
结语
企业级 Agent 的经济性，取决于它能否用足够少的上下文完成足够可靠的任务。模型选择仍然重要，但知识检索、工具路由、记忆生命周期和性能评测决定了模型到底要处理多少信息、调用多少次以及是否需要重试。
把上下文工程纳入 Agent 的设计和运营流程，成本优化就不再是上线后的临时降价动作，而会成为可测量、可迭代的系统工程。