从 Schema 到 Evidence,让 Agent 的输出经得起较真

作者：袖梨 2026-08-17

上篇我们把简历 Agent 推进到了"结构化输出字段校验可调 Tool"。但真实简历一扔进去,还是露了三处破绽:字段不够细、模型会编、给的建议是一句空话。

今天这篇顺着这三处破绽,把数据结构从"能跑"推进到"能较真":Schema 做业务建模、missing_fields 暴露缺失、Evidence 绑定原文,最后给出可落地的结构化建议。

一、Schema 不是字段堆砌,是业务建模

入门时用一个扁平结构:

代码语言：python

复制

class ResumeSummary(BaseModel):name: strsummary: strskills: list[str]

真实简历不是三段话,它有层级。于是拆成多个模块:

代码语言：python

复制

class ResumeProfile(BaseModel):basic_info: BasicInfoeducation: list[Education]work_experiences: list[WorkExperience]projects: list[Project]skills: SkillSetsummary: strmissing_fields: list[str]

这一步的关键认知:

简历不再是一段文本,而是一个有层级的对象。下层每一个 BasicInfo、Education 都是独立的 Pydantic 模型,各自带自己的字段约束。模型越贴近真实业务,输出越不容易"串味"。

二、missing_fields:让 Agent 承认"我不知道"

跑起来后,Agent 返回了这样的缺失清单:

代码语言：json

复制

"missing_fields": ["basic_info.phone","education.major","work_experiences.title","work_experiences.start_date","work_experiences.end_date"]

注意它没有硬猜手机号和专业,而是把判断不了的信息用点号路径标出来。

这很重要。很多 AI 应用的问题不是"答不出",而是"不知道还硬答"。missing_fields 的作用是:让 Agent 把无法判断的信息显式暴露出来。

暴露之后,下游就能:

提醒用户补充走人工审核降低整体置信度避免拿不完整的结果去入库

三、Evidence:每个字段都能回到原文

之前的写法,字段只有值:

代码语言：python

复制

school: strdegree: str | None

今天升级成"值出处":

代码语言：python

复制

class EvidenceText(BaseModel):value: strevidence: str

输出长这样:

代码语言：json

复制

"school": {"value": "北京工业大学","evidence": "北京工业大学,工学硕士,2009.09-2012.06。"}

解决的问题是:这个字段到底是不是原文里真的有?

没有 evidence,模型可能吐一个看似合理但查无此处的结论。加了 evidence,每个关键字段都能拉回原文核对。

今天立的三条铁律:

没有 evidence 的关键结论,不进入最终结构。evidence 必须是原文片段,不是模型的解释。找不到 evidence,就返回 null / unknown / []。

四、结构化建议:不是散文,是四条

普通 AI 容易输出这种话:

有道理,但不可执行。

今天把建议压成固定结构:

代码语言：python

复制

class SuggestionItem(BaseModel):issue: strreason: strevidence: strrewrite: str

每条建议必须回答四件事:什么问题、为什么是问题、原文依据、怎么改。

代码语言：json

复制

{"issue": "项目描述缺少具体技术动作和成果","reason": "原文只写了负责数据中台建设,无法体现具体贡献和结果","evidence": "负责数据中台建设。","rewrite": "负责数据中台建设,结合 Python、Spark、Flink 等技术支撑数据处理与实时计算场景。"}

价值很清楚:建议不再是泛泛而谈,而是可展示、可追踪、可人工审核、可继续改写。