结构化数据的幻觉：从求职API看AI Agent的数据解释困境

一位开发者构建了求职搜索API，返回干净JSON格式的职位、公司、地点、薪资等字段。测试阶段一切完美，但当他把API交给AI Agent使用——比价、按薪酬过滤、监控新职位——才发现薪资字段一半是噪音。这个案例揭示了一个被忽视的真相：结构化数据的形式化不等于语义可用性，而对于依赖数据做决策的AI Agent来说，解释层的质量才是真正的产品价值。

同一个职位，三种薪资，四个数字

同一个公司在柏林发布的"高级工程师"职位出现了三次，薪资范围分别是€70–90k、€85–110k，还有一个干脆没有薪资。去重键（标题+公司）本身没问题，问题出在数据上。开发者最终采用规范化标题+公司+地点聚类，把薪资当作分布而非点值来处理。

这暴露了聚合类数据API的根本矛盾：不同时间、不同招聘渠道、不同HR发布的同一职位，可能携带完全不一致的薪酬信息。如果Agent把每个薪资当作确定事实，决策就会出现偏差。

对构建Agent系统的开发者而言，这意味着薪资字段需要携带"来源"和"时间戳"元数据，才能让下游推理合理判断哪个数字更可信。

去重键的局限性与聚类策略：传统去重依赖精确匹配的键（如“标题+公司”），但招聘市场天然存在软性重复——同一职位因渠道、语言、发布时间差异而标题微调（如“Senior Engineer”与“高级工程师”），精确键会漏判。更鲁棒的方案是采用模糊聚类：对标题和公司名做规范化（小写、去除修饰词、统一语言），再结合地理位置与时间窗口做相似度分组。聚类后，薪资不再视为点值，而应建模为分布（如取中位数、分位数或区间并集），供下游Agent按置信度消费。同时，每个薪资应附带来源渠道、抓取时间、HR归属等元数据，使Agent能动态评估可信度，而非盲目信任单一数字。

"有竞争力"也是一种值——别丢掉30%的市场

约30%的职位在schema期望数字的位置放了字符串。开发者的第一反应是丢弃这些行。但这个直觉是错的——等于扔掉了三分之一的市场信息。

正确的做法是：解析能解析的，标记不能解析的，让调用方决定。"有竞争力""面议""根据经验"这些字符串本身就是信号，说明该职位薪资不透明，这恰恰是做市场分析时的重要维度。

这与AI Agent的数据消费模式有关。Agent不像人类UI那样可以"忽略"空字段，它需要明确的标记来判断哪些数据可以参与推理、哪些应该触发回退逻辑。

货币不归一化就等于谎言

£60k、60000 GBP、60,000£、€60.000——欧洲小数点用逗号、符号位置不固定、税前税后gross/TC标签埋在描述里。这些变体如果不做归一化，任何跨地区薪资比较都是无意义的。

开发者加入了一个归一化层，提取金额+货币+周期（年/月/时），统一转为年化数字。虽然有时仍会出错，但错误是一致可过滤的，而不是随机混乱。这个区别很关键：Agent系统需要的不是完美数据，而是可预测的错误模式。

对于任何处理多源地理数据的AI应用，货币归一化都不应该是可选项，而应该是数据管道的必备层。

金额归一化的技术细节：货币归一化远不止汇率转换，它包含三个正交维度——金额解析（处理千位分隔符、小数点符号、货币符号位置）、货币识别（从符号、代码或上下文推断ISO 4217代码）和周期标准化（年/月/日/时换算）。欧洲数字格式常以逗号作小数点（如€60.000表示六万欧元），而英美则相反，这要求解析器具备地域感知能力。此外，税前（gross）与总薪酬（TC）的区分需从文本标签或描述中提取。归一化后应输出统一结构（如{amount: 95000, currency: 'EUR', period: 'year', type: 'gross'}），并保留原始字符串作为审计线索。即使存在解析错误，只要错误模式一致（如特定来源总是误读），下游即可通过过滤规则规避，这比随机混乱更可控。

描述字段才是真正的薪资来源

结构化薪资字段经常只是占位符。真实数字往往藏在"薪酬最高€95k，视经验而定"这类句子里。开发者增加了一个轻量提取层，从描述中抓取候选数字，并标记为estimated: true，防止下游Agent将其当作权威数据。

这个设计决策值得借鉴：同一条数据在不同置信度下应该有不同的消费方式。高置信度的结构化字段可以直接用于过滤和排序，低置信度的提取值只能用于探索性分析或作为排序的次要因子。

置信度标记的设计原则：为数据附加置信度标签（如confidence: high/medium/low或estimated: true）是构建推理型API的核心。高置信度来源包括直接的结构化字段（如Schema.org的baseSalary）或官方披露；中等置信度可源于多条描述的一致性提取；低置信度则来自单次模糊匹配或第三方估算。Agent应据此分级消费：高置信度数据用于硬过滤（如“薪资>80k”）、排序主键；中低置信度数据可用于探索性分析、补充排序因子或触发人工复核。同时，API应返回source_note说明数据出处，例如“从职位描述中提取，原文：‘薪酬最高€95k’”，让Agent在推理链中透明引用。这种设计将数据的不确定性显式暴露，而非隐藏，从而避免下游做出过度自信的决策。

API设计需要从"展示"转向"推理"

这个案例的核心转变是思维模式的切换：从"API返回结构良好的数据供人查看"转向"API返回带语义标注的数据供Agent推理"。

开发者最终的API返回原始字段加上confidence提示和source_note。数据更乱了，但真能用了。

这对正在构建Agent应用或数据管道的团队有直接启示：schema不是产品，解释才是。如果你的API输出会被AI Agent消费，花在归一化和置信度标注上的时间，远比优化字段命名和文档格式更有价值。

开发者把整个方案打包成了单一端点（关键词+地点输入，返回归一化去重后的职位），可以作为Agent工具链中的数据层参考实现。