Agent 的决策能力最终要落到模型上。模型如果没理解目标、没识别工具参数，后面的工作流设计得再漂亮也只能得到错误动作。

所以在进入工具调用之前，有必要先把大语言模型看成一个“能力很强但需要检查的实习生”：它能理解自然语言、总结材料、提出计划，但不天然知道事实，也不会自动遵守业务规则。

Token 是模型处理信息的基本单位

模型并不是按“字”来阅读文本，而是把输入和输出拆成 token。token 数量会影响上下文长度、价格和延迟。

这解释了三个常见现象：

1. 一段看起来不长的中文，实际可能占用不少 token；
2. 聊天记录越积越多，模型会越来越贵，也可能接近窗口上限；
3. RAG 不是召回越多越好，过多片段会挤压真正重要的信息。

因此 Agent 的上下文管理不是优化细节，而是系统能否长期运行的基础。

Prompt 不是客套话，而是输入协议

一个可复用的 Prompt 通常要写清楚角色、目标、可用资料、输出格式和限制条件。仅仅说“请帮我处理这个问题”，模型需要自己猜很多东西；明确列出字段和停止条件，结果更容易稳定。

我会把 Prompt 看成一份输入协议：

任务目标：整理用户反馈
可用资料：仅使用 <documents> 中的内容
输出格式：category、summary、next_action
限制：资料不足时返回 insufficient_evidence

这不是为了把 Prompt 写得越来越长，而是为了减少隐含假设。真正重要的约束还要落在程序侧，不能只写在自然语言里。

Zero-shot、Few-shot 和推理策略

Zero-shot 直接给任务说明，适合简单分类和格式明确的任务。Few-shot 通过示例告诉模型“什么叫合格答案”，对边界情况通常更有帮助。需要多步推理的任务，可以要求模型先给出计划或中间结构，再生成最终结果。

不过我不会把“让模型展示思考过程”当成可靠性保证。真正可验证的是中间状态、工具结果和最终结构，而不是一段看起来有逻辑的解释。

Temperature 不是智能程度旋钮

Temperature 更像输出随机性的调节器。创意写作可以提高一些，分类、抽取和工具参数生成通常更需要稳定。

模型选型也不能只看排行榜。需要同时考虑上下文长度、工具调用、结构化输出、图片或音频能力、延迟、价格和隐私要求。一个很强但很慢的模型，不一定适合每一步 Agent 调用。

模型知道的，不等于系统允许它做的

模型可能记得某个 API 的用法，却不知道今天的库存；可能根据常识回答政策，却没有看到企业内部的新版本；可能生成了合法的 SQL，却没有权限执行。

因此 Agent 需要把模型能力和外部事实分开：事实通过检索或工具获取，动作通过权限和规则控制，输出通过解析和验证接收。

这章给我的启发

LLM 的价值在于语言理解、信息组织和不确定任务的推理，但它不是数据库、权限系统和事务引擎。

把模型当成能力组件，而不是最终权威，后面的 Agent 架构会更清醒：该补资料时用 RAG，该执行动作时用 Tool，该保存状态时用 Memory，该防止越界时用 Harness。

文章摘自：https://www.cnblogs.com/hazy-star/p/22622926