1. Skill 管理与 System Prompt 优化
问题：Skill 太多占用上下文窗口
方案：
- Skill 做成外部注册表，system prompt 只保留最小规则和调用协议，按需动态注入
- Skill Routing：用规则/分类模型/向量检索筛 top-k skill
- Skill 信息拆成摘要版和完整版，先注入摘要，确认调用后再加载详细说明，显著压缩 token
2. Skill 消歧（Description 相似导致误召回）
解决思路（四步走）：
- 将 skill 从纯文本 description 升级为结构化定义（适用场景、禁用场景、输入参数、返回格式、前置条件、失败条件、调用示例）
- 两阶段选择：先召回 top-k → 再让模型根据参数约束和样例做 rerank
- 加入负样本示例，明确告诉模型什么问题不应该调用这个 skill
- 执行前做 schema 校验和 rule check，即使模型选错也不能继续误调
长期方案：如果两个 skill 语义长期接近，考虑在系统设计层面合并成一个 skill，再由内部参数路由
3. Agent 设计核心 — 上下文工程
Agent 最终不是单轮问答，而是一个持续决策系统。模型能看到什么信息、这些信息的顺序和优先级、哪些是规则/证据/历史状态，都会直接影响 Agent 的稳定性。
核心原则：不是"给模型更多信息"，而是"给模型正确的信息"。
4. 上下文工程注意事项
| 要点 | 说明 |
|---|---|
| 角色隔离 | system、developer、user、tool output、memory 的优先级和边界要清楚，外部文本和系统规则不能混在一起 |
| 信息裁剪 | 只保留当前任务相关内容，避免把所有历史对话/检索结果/工具说明一股脑灌进去 |
| 格式控制 | 结构化上下文比纯自然语言更稳（工具结果用 JSON、任务状态字段化、长历史做摘要） |
| 来源可信度分层 | 系统规则 > 用户输入 > 工具结果 > 模型猜测 > 无依据生成 |
| 上下文压缩与淘汰 | 长任务需做压缩和过期淘汰，避免状态漂移和旧信息污染新决策 |
5. 长期记忆设计（写回、衰减、冲突消解）
写回策略
- 只保存高价值稳定信息：用户偏好、身份属性、长期任务目标、反复出现的业务事实
- 做结构化抽取（如
profile字段），而非原文整段存储
衰减策略
- 短期热点信息：高权重，随时间衰减
- 长期稳定偏好：低频刷新，不轻易删除
冲突消解
- 结合时间戳、来源可信度、置信度
- 新的高可信事实覆盖旧事实，低可信内容只作为候选
高级方案
- 事件流 + 物化视图：所有记忆写入先存成 event，再异步聚合成 profile，方便审计和回滚
6. 并行 Tool Calling
核心要点：
- 只有互不依赖的工具才能并行（如天气查询和汇率查询可一起发）
- 有依赖关系的必须串行
一致性保障：
- 工具执行结果先写到临时观察区，再由调度器统一合并，避免并发写导致状态污染
可回放性：
- 每次调用带
trace_id、step_id、输入参数、输出结果和耗时，组成完整执行 DAG
失败处理：
- 按工具粒度重试，不能因为一个工具超时就把全部结果丢掉
副作用操作：
- 发消息、创建订单等需加幂等键，防止重复重试造成真实业务重复写入
7. 主流 Agent 设计模式
| 模式 | 特点 | 适用场景 |
|---|---|---|
| ReAct | 边推理边行动（思考→调用→观察→继续思考） | 通用场景 |
| Plan-and-Execute | 先规划再按步骤执行 | 长任务，比纯 ReAct 更稳 |
| Router | 先做任务分类，再路由给不同子 Agent/工具链 | 多能力分发 |
| Workflow + Agent | 固定流程嵌局部自主决策 | 线上业务常用 |
| Supervisor | 主 Agent 拆解任务并分派给多个子 Agent | 多 Agent 协作 |
| Blackboard | 多 Agent 通过共享状态协作 | 多 Agent 协作 |
| 点对点自由协作 | Agent 间自由协作 | 线上较少，不易治理 |
8. MCP vs A2A vs Function Calling
| 协议 | 抽象层级 | 适用场景 |
|---|---|---|
| Function Calling | 调用一个函数 | 单应用内工具调用，模型输出结构化调用意图，宿主进程负责执行 |
| MCP | 暴露一组标准能力 | 多模型客户端/IDE 共享一套工具和资源能力，统一封装资源、工具、提示模板 |
| A2A | 多智能体协作完成任务 | 多 Agent 分工协作、任务转派和结果汇总 |
本质区别：抽象层级不同 — 函数调用 → 能力暴露 → 智能体协作
9. RAG 接入 Agent 的设计
- RAG 应作为决策节点，而非固定的"先查再答"
- 模型先判断是否需要外部知识 → 决定 query rewrite → query decomposition → 召回 → rerank → 生成
- 常见做法：把 RAG 包成一个工具，Agent 自己决定何时调用
- 检索结果需做去重、切片、排序、来源标注
- 生成时要求模型只根据检索到的证据回答，没有证据就明确说不确定，降低幻觉
10. Tool Calling 工程实现
四层架构：
| 层级 | 职责 |
|---|---|
| 工具注册层 | 管理可用工具 |
| 参数 schema 层 | 定义参数格式和约束 |
| 执行器层 | 实际执行工具调用 |
| 审计日志层 | 记录调用链路 |
服务端职责：白名单校验、参数校验、超时控制、幂等控制、错误包装
核心原则：模型只能输出候选调用，不能把工具执行权直接交给模型
11. Agent Memory 分层
| 层级 | 用途 | 特点 |
|---|---|---|
| 短期记忆 | 最近几轮对话 + 当前任务状态 | 保证会话连贯 |
| 长期记忆 | 稳定事实（用户偏好、身份、目标） | 持久化存储 |
| 摘要记忆 | 压缩旧对话为关键事实 | 减少 token 占用 |
落地策略：保留最近 N 轮原文 → 更久远内容压成 summary → 抽取关键字段单独存储 → 按需召回，不全量拼接
12. Prompt Injection 防护（Agent 场景）
风险：不仅生成错误文本，还可能误调工具、越权执行、触发真实业务操作
分层防护：
- 角色和优先级隔离：外部知识不能覆盖系统规则
- 文档视为证据：检索文档视为证据，不视为命令
- 工具调用管控：白名单 + 参数校验，高风险操作显式确认
- 链路可追踪：输出和调用链路必须可追踪，出问题能回放
- 输入清洗：对明显越权或诱导内容做拦截
核心思想：靠系统设计让模型即使被诱导，也没有越权能力
13. Agent 效果评估（四层）
| 层级 | 评估维度 |
|---|---|
| 回答质量 | 准确性、完整性、是否基于证据 |
| 工具质量 | 选工具是否正确、参数是否正确、调用是否成功 |
| 任务质量 | 一次会话是否完成目标、是否需要额外追问、是否需要人工接管 |
| 系统质量 | 耗时、成本、token、错误率、稳定性 |
如果有 RAG，还需单独评估：召回命中率、rerank 效果、答案引用质量
核心观点：Agent 不是单个模型的分数，而是整条链路的分数
14. 线上工具选错排查路径
- 检查 tool description 和 schema 设计，边界是否模糊，参数是否能区分场景
- 检查 skill routing 层，是否一次性喂了过多候选工具造成噪声竞争
- 检查 prompt 和 few-shot 示例是否给了错误引导，或是否最近改过 system prompt
- 回放 trace，检查模型选工具前看到的上下文、历史记忆是否污染当前判断、用户输入是否歧义严重
排查原则：不是看最后一步，而是看"候选集是怎么来的、模型为什么这么选、执行前有没有二次校验"
15. 长任务防死循环
限制手段：
- 最大推理步数
- 最大工具调用次数
- 最大 token 开销
- 最大执行时长
条件定义：明确什么叫完成、什么叫失败、什么情况需要让用户补信息
重复动作检测：连续多步调用同一工具/得到相似结果/没有带来新证据 → 强制终止并返回阶段性结论
总结
Agent 系统的关键不在于模型能力有多强，而在于：
- 上下文工程：给模型正确的信息，而非更多信息
- 系统设计：安全边界、校验层、可回放
- 分层架构：记忆分层、评估分层、防护分层
评论 (0)