作者无哲也许你也曾经遇到过这样的场景线上突发故障你顺着线索一路排查终于锁定了一个随新版本上线、包含关键信息的日志字段。但点击查询时系统却提示“该字段未配置索引无法进行分析”。在半结构化日志日益普及的今天写入端可以灵活扩展字段分析端却仍然依赖预先配置的索引。每次发版带来新字段都要手动补索引对于历史数据可能还要再等待索引重建。这使得“写入的灵活”并没有完全转化为“分析的便利”。AI Agent 的兴起则让这个矛盾更加突出。Agent 在执行任务时会动态生成新的日志字段在多轮“推理—检索”中也会根据中间结果不断调整查询分析路径。这些字段和分析需求都在运行时产生难以提前预设也无法每次都依靠人工实时跟进索引配置。为此阿里云日志服务 SLS 推出自动发现字段索引功能让索引具备自适应数据变化的能力自动为新写入的字段创建索引并开启统计无需手动干预。无论是开发运维人员还是 Agent都无需逐个配置字段索引就能使用新字段进行分析从而实现数据的开箱即用。手动维护索引越来越难跟上变化字段很难在接入时一次确定通过字段索引进行日志查询和 SQL 分析通常需要先确定字段再配置索引。当日志结构稳定、查询需求明确时这套方式很容易落实。但实际业务中的字段往往是逐步增加的。应用升级会带来新的观测信息接入不同数据源会引入新的日志结构还有一些字段只在特定条件下出现。接入时看到的日志样本很难覆盖后续所有数据。于是维护索引也成了一项持续的工作每次新增字段都要考虑是否需要查询、是否用于分析以及相应的索引是否已经配置。业务变化越快这项工作就越难做全。用到字段时才发现还没有索引字段有没有索引往往到真正使用时才会被注意到。新的查询需要增加一个过滤条件统计需要换一个分组维度却发现对应字段还没有建立索引。此时再添加索引分析就要等待如果还需要覆盖已经写入的历史数据则可能需要重建索引当历史数据量较大时等待的时间也会被拉长。数据已经存在却不能马上分析。原本可以继续深入的问题卡在了索引准备这一步。Agent 让日志字段和查询需求更难预先确定当日志由 Agent 生成和写入时日志内容会随着任务、工具调用和执行结果变化。不同任务可能记录不同的字段执行过程中也可能增加新的状态和中间结果很难在接入之初就完整确定日志结构。当 Agent 负责分析日志时分析路径同样难以提前预设。分析过程中Agent 通过多轮推理—调用工具—观察结果推进任务借助字段检索缩小范围再通过 SQL 完成聚合、排序和对比。每一轮结果又会决定下一步查询哪些字段、验证什么假设查询需求随着推理过程动态产生。如果分析过程中发现字段没有索引就可能需要暂停查询等待索引补建或重建甚至由人工介入处理打断原本连续推进的推理与工具调用。SLS 自动发现索引新字段自动建索引无需逐个配置开启自动发现索引后SLS 会在数据写入时自动识别未配置索引的新字段为其构建索引并更新索引配置。持续发现自动创建索引并开启统计自动发现索引会持续检查新写入的日志。遇到尚未配置字段索引的顶层字段时SLS 自动为其创建字段索引并开启统计使其能够参与字段查询和 SQL 分析。这项能力会随着日志写入持续工作。应用后续增加的字段、不同数据源带来的字段以及接入时尚未出现的字段都可以在实际写入时被发现无需每次新增字段后再手动补充配置。对于应用开发者新增日志字段时少了一项同步维护工作对于数据使用者分析时可以直接使用这些新字段自由调整查询条件和统计维度。写入即构建无缝覆盖配置可见前的数据开启自动发现索引后SLS 会在日志写入时立即为新字段构建索引。索引构建与字段配置的生效是两个独立的过程——构建会随写入立即开始配置可见需要一定的同步时间。这意味着在配置尚未可见的这段时间里写入的数据索引同样会被构建。待配置生效后这部分数据可以直接用于查询和分析无需补建或重建索引。统一按 text 建索引兼容类型不确定的字段在自动发现字段时仅凭字段首次出现时的值很难准确判断其真实的业务类型。例如某新字段写入的第一条日志值是 123看似是数值但后续写入的完全可能是abc例如随机 ID。如果贸然在首次探测时将索引类型固定为数值型后续遇到非数字字符时就会面临类型冲突。为此SLS 对自动发现的字段统一采用 text 类型建立索引。这种高兼容性的设计能够包容各种格式的字段值确保任何格式的新字段都能顺利写入并生成索引避免因类型判断不准而导致的冲突与漏建。SQL 类型自适应转换免去类型声明虽然底层统一以 text 类型存储但这并不影响数值类计算的便利性。在进行 SQL 分析时针对自动探测出来的字段SLS 引擎在遇到数值类表达式时会自动在运行时将字段值转换为数值类型。对于无法转换为数值的值会自动跳过。相当于将sum(x)自动转换为sum(try_cast(x as double))。这样通常情况下无需专门将自动探测出的字段改为数字类型就可以直接按照数字类型去写 SQL使用起来更加方便。如何开启和使用自动发现索引在控制台开启自动发现索引进入目标 Logstore 的索引配置页面确认全文索引已开启勾选“非指定字段自动发现需开启全文索引”并保存即可开始持续发现新写入日志中的字段。控制台开启入口按账号分批开放中如果暂未被灰度到可以提交工单联系开启白名单。查看自动发现的字段开启后继续向 Logstore 写入日志。新出现的字段会自动建立索引随后可以在索引配置页面的“自动探测字段”区域查看。这些字段索引的类型都是 text 类型分词符、是否大小写敏感、包含中文这些属性和全文索引相同并且默认开启了统计。如果需要修改自动探测出的字段属性可以点击字段上面的 号提升为手动配置字段然后再进行修改其相关属性。使用自动发现的字段进行查询分析待字段配置可见后就可以在日志查询界面使用这些自动探测字段进行字段查询、快速分析和常规 SQL 分析使用方式与手动创建的字段索引完全一致。自动探测字段默认开启统计可以进行 SQL 分析。自动探测字段在索引层面是 text 类型但在 SQL 中也可以直接视为数字类型去使用。通过 SDK 开启和管理自动发现的字段SDK 方式已经全地域支持无需添加白名单即可使用。在索引配置的 json 中line字段的auto_key_detect: true表示开启自动发现索引的能力。auto_text_keys表示自动发现出来的索引字段。{ line: { auto_key_detect: true, auto_text_keys: [status, code, latency] }, keys: { } }SDK 也提供了相关接口来操作以 python sdk 为例0.9.52版本及以上。from aliyun.log import IndexConfig, IndexLineConfig #开启自动发现索引 client.create_index( project, logstore, IndexConfig(line_configIndexLineConfig( token_list[ , ,, ;, \n, \t], auto_key_detectTrue, )) ) #获取自动发现索引相关配置 index client.get_index_config(project, logstore).get_index_config() print(是否开启自动发现:, index.line_config.auto_key_detect) print(已发现的字段:, index.line_config.auto_text_keys)关于自动发现索引的更多配置细节、使用限制、常见问题等说明请参考官网文档https://help.aliyun.com/zh/sls/automatic-field-indexing。总结随着 AI Agent 深度参与到任务规划与问题分析中底层数据系统正迎来一次角色转变查询需求不再能够被提前预设而是在运行时动态产生的。为了支撑这种高频、不确定的探索现代数据系统不仅要利用弹性容量和高效检索去处理大模型无法直接消化的大规模数据更要把字段识别、索引构建等前置工作自动完成减少分析过程中的等待与人工干预。自动发现索引正 SLS 沿着“数据自适应”方向迈出的一步。弹性容量应对规模变化灵活 Schema 允许结构演进而索引自动发现则保证了新增字段的即时可用。当底层配置不再成为探索的限制无论是开发者还是 AI Agent都能更纯粹地专注于业务问题本身真正实现数据的开箱即用与自由分析。