2026.9.29：
项目介绍
我在一个面向人际关系管理的 AI 助手里，做了一轮 Agent 调优和 Harness 工程改造。最初发现两个比较实际的问题：第一，简单对话也消耗约 3,000 多 token；第二，用户描述一件事、经过几轮澄清后，模型有时只口头说“已经记录”，却没有生成可确认的结构化操作建议。用户接着回复“是的”时，模型还可能因为上下文没带全而丢失指代。
我先沿着真实调用链分析 token 和行为来源，而不是只改 prompt。发现每次请求都带着体量较大的操作 schema 和联系人、字段、提醒等业务上下文；同时，历史消息、session 摘要和工具操作状态之间缺少明确的上下文策略。
随后我做了几类改进：
- 按意图路由 prompt：普通问答走轻量 prompt，明确涉及创建或修改联系人、互动、提醒时才加载完整 action schema；短回复则结合最近对话和待确认操作状态判断是否仍在操作流程里。
- 动态裁剪上下文：普通聊天不再带完整业务数据。根据请求意图只附相关信息；例如联系人维护才提供匹配联系人的详细资料，提醒操作才提供相关提醒。空数组会省略，JSON 也改为紧凑序列化。
- 增加 session 多轮记忆：保留当前 session 的近期原文；旧对话超过阈值后，后台增量压缩成摘要并保存在 session 中。摘要生成不挡当前回复，原文仍保留在本地，出现摘要失败时不会丢历史。
- 强化 action 输出约束：联系人资料使用文本、日期、联系人引用等显式类型，更新优先使用稳定 ID；目标不明确时追问。同样要求有效 action 才能成为操作建议卡，缺少 action 时不能说“已经执行”。
- 补充用量可观测性：把输入和输出 token 分开展示；如果一轮触发了后台摘要调用，也合并计入该轮，便于之后基于真实 usage 继续优化。
这轮工作的重点不是让模型“更会说”，而是让 Agent 的上下文、输出协议、操作执行和确认状态对齐。iOS 构建、后端语法和静态诊断均通过。
工程方法
这次优化体现的是一个闭环：从用户可见故障和 token 用量定位问题，检查完整请求链路，再修改意图路由、上下文裁剪、结构化 action schema、服务端校验和客户端确认展示，最后通过 token 拆分让优化结果可观测。
需要如实说明：虽然实现了更轻的上下文策略和 token 明细展示，但还没有部署后做前后 A/B 或真实请求用量对比，所以目前不能声称节省了某个百分比（其实可以看到从 3600 多变成了 1100 多）。下一步应采集普通聊天与操作规划两类请求的输入/输出 token、延迟和 action 成功率，再根据数据调整路由规则和上下文预算。
最新回复