001 agent_eval项目介绍

1、项目介绍
1.1 该项目是小助手智能问答项目，用于问答人事相关问题咨询：人才筛选、制度查询、FAQ、绩效总结、办事等。
Claude Coder提供开源，其Harness架构为智能体提供驾驭（Agents = Model + Harness），Harness作用
（1）管住模型不乱跑：Model容易幻觉，Harness通过规则、权限管控幻觉；
（2）记住不遗忘、纠错：Harness提供文件系统和记忆机制；且内置自动校验和纠错机制
（3）调用外部工具：通过标准协议（MCP）把外部（搜索引擎、数据库、API）调用起来，变成能干活

1.2 新模式：Harness + TAOR
（1）动态规划，AI自主拆解任务、组合工具
（2）TAOR模式：Think-Act-Observe-repeat
（3）去掉复杂意图识别，模式ReAct，变思考变行动，性能瓶颈在于工具执行时间
（4）模型思考是否触发兜底降级处理，更加智能化

2、目标和业务价值
2.1 业务目标
| 目标 | 详情 |
| ---------------------------------- | --------------------------------------------------------------------- |
| 从“流程正确性”转向“Agentic能力”测评 | 实现评测结果可归因、可溯源、可驱动优化，形成“测评→反馈→优化→再测评”闭环 |
| 实现自动化、规模化评测能力 | 支持每日/每周自动运行评测，覆盖90%+常见场景，覆盖PC与APP双端 |
| 构建问题根因分析机制 | 实现全链路性能与质量观测，不仅知道“答错了”、“太慢了”，还要知道“为什么错”、“为什么慢”，支持从指标反向推理prompt
LLM选型、skills编排、tools定义等关键模块优化，让用户真切感受到小助手越用越聪明 |
| 沉淀高质量评测数据资产 | 构建可复用的“评测样本库 + 标准答案库 + bad case案例库”，形成数据飞轮
✅ 从CMS收集真实用户问题+精准答案，作为核心评测集；
✅ 采用AI生成 + 人工标注 + 多轮校验模式进行数据增强，提升覆盖率与多样性；
✅ 建立评测集版本管理机制，支持灰度发布与A/B测试对照；
✅ 按业务分类划分数据集子集，确保分布合理 |

2.2 业务价值
| 价值维度 | 具体体现 |
| -------------- | --------------------------------------------------------------------- |
| 从“凭感觉”到“看数据” | 每次版本发布前，可查看“意图准确率提升X%”“回答一致性得分达Y分”，实现决策可视化 |
| 评测效率提升10倍+ | 自动化评测替代人工标注，单次评测时间从“数小时”缩短至“数分钟”，让产品和研发将更多时间专注于本职工作，而不是繁琐的人工测评与case分析 |
| 问题发现从“被动”到“主动” | 通过趋势分析提前预警“某类问题准确率下降”，避免问题蔓延 |
| 构建智能体“自我进化”能力 | 评测数据反哺RAG优化、Skills编排、API设计，形成“测试 → 诊断 → 优化 → 再测试”的正向飞轮 |
| 支持高敏感场景准入 | 为“干部任免”“员工档案AI分析”等高敏感场景提供“评测通过”作为上线前提，保障安全与合规，保障用户使用体验 |
| 统一跨团队语言体系 | 研发、测试、产品、运营对“Agent质量”的理解一致，减少沟通成本 |

3、评测内容
3.1 Harness框架核心要点

问题	方案
核心引擎	Claude Code的harness架构：整个Agent的智能调度引擎，think--act--observer--repeat（TAOR）循环，所有工具都需要注册到Harness，Harness负责理解用户问题进行智能规划与工具执行
核心模块	（1）Session：会话管理，每个会话独立的context、TodoManager、TaskManager、SkillLoader

（2）AgentLoop（核心循环逻辑）：query→上下文压缩引擎→构建系统提示词（skills/todo/task/用户信息/时间信息/所处地址信息……）→调用Claude API（工具注册中心的tools，内含详细的工具描 述、字段说明）→执行工具调用→TAOR。
备注：
✅工具注册中心：包含基础工具（文件读写编辑bash等）、状态管理工具（TodoWrite、task的创建、获取、更新、列表查询、确认）、业务工具（档案查询、人员检索、邮件发送等），采用类似function calling的注册方式，工具描述甚至比提示词多，比如数据库字段的枚举描述
✅skill：每个业务对应不同的skill，内部定义api的调用方式与用途，业务api集成到统一的接口问答，后续调用哪个api时通过通用工具统一调用 |
| 智能问数 | （1）档案查询不再用字节的DataAgent，由模型提供筛选条件json，后台接口拼接sql
（2）内部写解析sql逻辑，所以速度快多了，主要是针对找人场景，所以sql不支持复杂的自由发挥，依赖于背后api解析筛选条件的逻辑
（3）内部做了库表和字段映射（类似以前机场的标准库设计），解决不同表的同名字段问题，所以根据AI筛选条件的字段就能知道调用哪个表 |
| 构权限问题 | 数据权限—字段权限（比如档案，有些字段应该所有人可见，如这个人是哪个部门，但有些是有不同权限的，比如绩效），由业务穷团队 |
| 业务新增 | 新增skill进行解耦管理 |
| 上下文管理 | 研发、测试、产品、运营对“Agent质量”的理解一致，减少沟通成本 |
| 解决了哪些问题 | （1）性能优化：耗时长的改用传统方式解决，真正动态变化的由AI解决，减少AI发挥空间，提升稳定性
（2）灵活度：更加Agentic，不再是呆板的workflow模式，由AI自己进行todo list规划与task执行，自行react
（3）智能化：AI进行意图理解与工具调用，尤其是多工具组合调用模式，以前无法支持的workflow分支或者multi-agent现在可拆解用户意图分别调用合适的工具执行再组合 |

3.2 评测内容
评测指标1：结果准确率
（1）确认评测维度：如事实一致性、逻辑完整性、信息覆盖度、错误类型（事实错误、信息缺失、幻觉等）等
（2）业务分类：确认需要评测的业务内容分类以及每类的问题分布比例
（3）评测集质量保证：保障评测集可作为标准答案评估，可从cms收集case，选择有代表性的问题+答案纳入评测集，并结合AI生成+人工标注进行数据增强
（4）审核Agent：确认裁判模型与评分标准prompt
（5）性能评估：写脚本分析评测集评测时的TTFT（Time To First Token）"

评测对象：端到端
指导意义（优化方向）
（1）分析智能体是否达到上线标准，可稳健运行
（2）分析业务上的知识库内容是否有错误、遗漏、过时，从而进行查缺补漏"
备注
（1）问数目前只考虑逻辑上的准确性
（2）初期PO阶段以制度作为MVP验证
（3）测评集并不是一成不变的，需随着业务变更进行回归迭代
（4）当前cms日志有记录query/answer/工具调用链路，但是是合并在一张表"

评测指标2：TTFT（Time To First Token，首字响应时间）
评测方法：
埋点记录整体耗时到cms日志表中
评测对象：LLM
指导意义（优化方向）
模型选型参考：推理类模型、通用对话模型等性能差异

评测指标3：API性能
评测方法：
提供一个统一的日志采集接口（或者java注解），支持各个工具、API进行日志记录（名称、参数、耗时）
评测对象：API、tools、skills
指导意义（优化方向）：
分析API本身是否需要进行性能优化，是否会阻塞LLM进程

评测指标4：工具调用准确率 "
评测方法：
（1）根据各个工具设计系列评测数据集，包含query&todo list
（2）根据上面的统一日志接口记录的内容与评测集对比，分析单个工具、多工具组合时的顺序、参数提取等准确性"
评测对象：
LLM 分析LLM的Harness规划调度能力、语义能力，用于指导模型选型，
备注：同时指导Tools的整体描述、参数描述是否合理或者需要优化

评测指标5：上下文一致性
评测方法：
准备需多轮推理的Q&A问答对，测评多轮对话中的指令遵循、意图推理、压缩是否丢失信息等，需包含基于query的推理、基于之前answer的推理
评测对象：上下文管理与压缩
指导意义（优化方向）：
分析压缩算法是否合理、上下文管理是否有其余优化空间

评测指标6：异常处理能力
评测方法：
测评harness的TAOR机制在面对接口超时、无权限、SQL出错等异常情况时能否触发兜底机制进行容错处理
评测对象：：TAOR
指导意义（优化方向）：：分析LLM的ReAct能否进行容错处理，分析兜底机制的设计合理性
备注：不同业务方向应当在skills中清晰设计兜底机制与降级处理方法。

评测指标7：安全合规性
评测方法：：
（1）测评功能权限、数据权限合理性，如同样是档案查询，查询人才有权限看权限限制，但是查询人员UM账号、邮箱、部门等基本公开信息应当无权限设置
（2）进行提示词诱导攻击，看是否越权"
评测对象：：功能权限、数据权限、prompt防御 分
指导意义（优化方向）：：析prompt的防御是否有漏洞、api权限设计是否合理
备注：建议统一接入权限管理规范