◇ 从RAG问答到Agent Harness：一个AI校园助手的实战升级之路

——

前段时间，我把一个已经跑了大半年的AI校园帮项目做了一次底层改造。这次改造没有加任何一个新功能，没有多接一个业务系统，甚至连用户界面都没变。但改完之后，整个项目的运营方式和迭代效率完全不一样了。

这篇文章就是这次改造的完整复盘。

一开始，它只是一个还不错的RAG问答助手

-

先交代一下背景。AI校园帮面向的是本科院校和高职院校的学生、家长和老师，主要解决教务、后勤、校园生活三大类问题。比如"高一学生怎么申请走读"、"饭卡丢了在哪补办"、"体育馆周末开不开放"这类。

架构上用的是比较经典的多Agent架构 + RAG方案：一个协调Agent做意图识别和任务分发，下面挂教务Agent、后勤Agent、校园生活Agent和一个通用兜底Agent。每条问题进来，先检索知识库，Rerank排序，然后把相关知识塞进Prompt，让对应领域的Agent生成回答。

效果数据也还不错——Top3准确率92%+，召回率85%+，端到端延迟控制在2秒以内。用户满意度NPS能到60以上。

看起来一切都挺好。直到有一次运营兄弟拿着一个点踩案例来找我。

一个点踩案例，暴露了根本问题

-

用户问的是："高二3班张同学的家长，孩子要请病假，需要交什么材料？"

系统回复了一段关于请假流程的通用说明，但没有具体到"高二3班"和"病假材料清单"这个粒度。用户点踩了。

运营同学想看这条回答到底哪里出了问题。然后我们发现，能看到的只有：用户问了什么、系统答了什么、用户点踩了。至于系统为什么这样回答——意图有没有识别对、有没有分发到教务Agent、检索回来的知识片段是什么、Rerank之后排第一的是不是正确答案、模型有没有读到正确的知识——这些全看不到。

这就是第一个痛点：只知道答错了，不知道为什么答错。

往后越查越发现，这不是个别案例的问题，而是整个系统缺少一层关键能力：Agent的运行过程没有被结构化记录。

换句话说，系统能回答问题，但不能解释自己为什么这样回答。

Harness这个概念，到底在说什么？

-

如果你一直在关注AI产品的工程化，应该已经注意到Harness这个概念了。Prompt Engineer、Context Engineer之后，就是Harness Engineer。

简单来说，Harness做的事情就是：让Agent的决策过程变得可记录、可追踪、可诊断、可优化。

Prompt Engineer是让表达结构化，Context Engineer是让数据源结构化。Harness Engineer更进一步——它让你和Agent每一次交互的完整链路结构化：意图怎么判断的、任务怎么分发的、知识怎么检索的、工具怎么调用的、答案怎么生成的。

回到AI校园帮的场景，Harness要解决的核心问题是：

💡

当学生家长问"病假要交什么材料"，系统答错了。你能不能在三分钟内，顺着一条完整的运行链路查下去，定位到这是知识库缺失、意图分发错误、Rerank排序翻车，还是模型生成幻觉？

如果你能做到，那就是Harness起作用了。

数据库原生Harness：让数据库成为Agent的运行底座

-

想清楚要做什么之后，设计就清晰了。我把这次升级称为"数据库原生Harness"，意思是用数据库来统一承载Agent的所有运行数据，而不是把日志、埋点、反馈散落在各个系统里。

核心思路很简单：每一次Agent执行，都生成一个唯一的run_id，然后把这次执行中发生的所有事情——意图识别、Agent分发、知识检索、Rerank排序、工具调用、答案生成、用户反馈——全部串到这条run_id上。

我做了8张核心表的改造：

sessions — 会话表。记录谁、在哪个入口、什么时候、什么身份发起的对话。这让后续分析可以按学校、角色、渠道来切分。

messages — 消息表。记录每一轮user和assistant的原始对话，保留语音识别文本。这是最基础的数据底子。

agent_runs — Agent运行表。这是整个Harness的核心。每一次Agent执行都是一条run记录，包含意图、分发的Agent、状态、耗时、模型版本、Prompt版本。这步改造让一次问答从"一条消息记录"升级成了"一个可分析的任务执行"。

agent_steps — 步骤表。把一个run拆成意图分类、检索、重排、工具调用、生成等多个阶段，每步记录输入摘要、输出摘要、状态和耗时。这让你能精确定位失败发生在哪一步。

retrieval_records — 检索记录表。记录每次RAG查询的query、召回的Top-K片段、Rerank后的排序、最终进入Prompt的片段。RAG问题到底是召回没命中、排序没排对、还是生成阶段没用好，一查就知道。

tool_calls — 工具调用表。记录课表查询、成绩查询、报修工单、场馆预约这些业务API的调用参数、结果、状态和耗时。业务系统稳不稳定，数据说话。

agent_memories — 记忆表。把以前只存在于Prompt里的"历史对话摘要"升级成可治理的数据资产：有来源、有置信度、有过期时间、可删除。比如"某位家长常问高二3班请假流程"这条记忆，什么时候生成的、从哪次对话来的、什么时候过期，全可以追溯。

evaluations — 评估反馈表。记录用户点赞点踩、人工标注结果、错误类型分类。关键是每一条评估都关联到具体的run_id，所以你知道用户不满意的是哪一次执行的哪个环节。

四个真实场景，看Harness怎么改变运营方式

-

表建好之后，最明显的变化是运营方式完全不一样了。举四个最典型的场景：

场景一：答错可追溯

同样是"病假材料"那个问题。有了Harness之后，运营同学查出这条对话的run_id，一路看下去：意图正确识别为教务场景，正确分发给了教务Agent，但检索环节发现——知识库里根本没有"高二病假材料清单"这个文档。Chunk召回的是"小学请假流程"。

问题定位：知识库缺失。后续动作：补充高中病假材料清单文档。从发现到修复，十分钟。

场景二：多Agent分发可优化

用户问"饭卡丢了在哪补办"，系统有时分发给校园生活Agent，有时分给后勤Agent，有时掉进通用兜底。有了agent_runs表之后，我们拉了一周的分发数据，发现"补办"这个词导致意图分类模型倾向于后勤类。调整了意图分类规则后，这类问题的路由准确率从72%提到了91%。

场景三：Memory支持连续服务

家长第一次问"我是高二3班张同学的家长，想了解请假流程"，系统把这条身份信息写入agent_memories。三天后家长又问"这次病假要交什么材料"，系统从Memory中召回上下文，直接定位到高二3班 + 病假场景，不需要再追问一遍身份信息。

同时，考虑到校园场景的隐私敏感性，Memory设置了过期时间、来源追溯和可删除机制。家长身份信息不能永久保存，也不能被其他学校的用户查询到。

场景四：评估集自动沉淀

每次用户点踩、触发兜底、或转人工，系统自动把这条run_id扔进错误案例池，并按错误类型打标签：意图识别错误、检索未命中、答案不完整、应转人工但没转。

两周下来积累了200多条标注好的错误案例。这些案例直接成为Prompt回归测试集和RAG效果评估集。以前做Prompt优化，只能靠感觉说"新版本好像好一点"；现在可以跑一遍错误案例集，数据说话。

关键指标的升级

-

原来我们只看四个数字：准确率、召回率、延迟、NPS。这些指标能告诉你"系统整体好不好"，但不能告诉你"哪里不好、为什么不好、怎么改"。

Harness升级后，我新增了九个指标：

◦ Agent路由准确率：协调Agent有没有分发给对的领域Agent

◦ 检索命中率：正确知识有没有进入Top-K

◦ Rerank有效提升率：Rerank有没有把正确片段排到更前面

◦ 兜底率：系统答不了或转人工的比例

◦ 工具调用成功率：对接的业务API稳不稳定

◦ 可解释失败率：答错的时候能不能定位原因

◦ Memory命中率：历史上下文有没有被正确召回

◦ 反馈覆盖率：多少比例的对话有用户反馈或人工标注

◦ 错误案例修复周期：从发现问题到修好要多久

这九个指标一上，项目的管理方式就从"效果达标"变成了"系统可治理"。

这次升级，我学到了什么

-

做完这次改造，我最大的感受是：一个好的AI产品和一个能持续变好的AI产品之间，差的不是模型能力，而是Harness能力。

模型能让你跑起来，但只有Harness能让你知道往哪个方向跑。

AI校园帮这个项目，用RAG和多Agent解决了"能不能回答"的问题，用数据埋点解决了"回答效果好不好"的问题，而数据库原生Harness解决的是"回答为什么不好、怎么变好、谁来改、改完有没有用"这一整条链路。

这让我想起之前写的另一篇文章里提到的：Harness Engineer的本质，是让你的决策过程结构化。对个人如此，对一个Agent系统更是如此——如果Agent的运行过程不能被记录和诊断，你的优化就永远是盲人摸象。

另外还有一个意外的收获：有了完整的运行轨迹数据之后，我们积累的不仅仅是问答记录，而是一整套可复用的数据资产——意图分类数据集、RAG评估集、工具调用分析集、Memory样本集。这些数据对后续的模型微调、知识库优化、Prompt迭代都是直接可用的燃料。

做AI产品这件事，长期来看，谁的Harness做得好，谁的数据飞轮就转得快。

所以说Harness的设计是数据飞轮的核心，我觉得听别人说一万次Harness，真不如从底层数据层面玩一次Harness，这样才能真的悟。

实施建议

-

如果你也在做类似的Agent产品，我的建议是不要一上来就追求完美。AI校园帮这次改造分了六个阶段，每个阶段都有明确的交付和验收标准：

第一阶段先把agent_runs和agent_steps建起来，保证任意一次问答都能通过run_id找到完整执行过程。这是整个Harness的骨架，两周就能搞定。

第二阶段再管RAG链路，加retrieval_records，让检索问题可诊断。

第三阶段接工具调用记录，第四阶段做Memory资产化，第五阶段建评估反馈闭环，第六阶段才是数据导出和训练闭环。

不要一上来就想把八张表全部建完，先从最痛的场景开始——能追溯一条答错的记录，就已经值回改造成本了。

· · · · · ·

这次实战的完整复盘就到这里。如果你在做类似的事情，或者对Agent Harness有不同理解，欢迎在评论区聊聊。