智能体轨迹压缩成自动机行为更多由框架决定这次我们来看一个偏研究向但工程价值非常明显的话题把智能体的运行轨迹压缩成自动机然后观察一个很关键的结论——智能体的行为更多是由框架决定的而不是模型本身。这个结论听起来有点反直觉。很多人默认“智能体聪明不聪明主要看底层大模型”但把轨迹数据压缩成确定型自动机之后你可以直观地看到同一套框架下不同模型跑出来的行为路径高度相似反而是换一套框架行为结构会发生明显变化。这意味着什么意味着你在做智能体应用落地时框架设计比换模型更值得花精力。这篇文章会围绕“智能体轨迹压缩成自动机”这个主题拆解几个核心问题轨迹压缩成自动机的原理是什么怎么落地验证环境怎么准备如何用一套最小实验流程复现“行为由框架决定”这个结论以及实际工程中该注意哪些坑。如果你正在做 Agent 框架选型、智能体行为分析、可观测性设计这文章值得收藏。1. 核心能力速览能力项说明项目类型智能体行为分析 / 轨迹压缩 / 自动机结构识别核心输入智能体运行的轨迹日志如 JSONL、CSV、数据库导出的行为记录核心输出确定型自动机DFA以及行为路径的聚类与频次统计关键结论同框架下不同模型行为路径相似度更高框架对行为结构的塑造力大于模型本身技术基础轨迹压缩算法、确定性有限自动机、行为嵌入、聚类分析建议环境Python 3.9内存至少 8GCPU 即可完成小规模验证无需 GPU启动方式命令行脚本或 Jupyter Notebook分阶段执行压缩与可视化是否支持 API可以把压缩后的自动机序列化成 JSON供上层系统读取是否支持批量任务支持按多轮轨迹批量压缩脚本循环处理即可适合场景Agent 框架选型对比、智能体行为可观测性、异常行为检测、轨迹数据挖掘从材料看这个项目不依赖大模型推理不需要 GPU 和显存。重点在数据处理、状态合并、结构识别。所以哪怕只有一台普通办公电脑也能把整套流程跑通。2. 适用场景与使用边界这个思路适合谁可以解决什么问题先说适用场景。第一个典型场景是框架选型。比如你想比较 Dify、Coze、自研 Agent 框架、或者某个开源 Agent 框架之间的差异不再是只看功能列表而是让一批任务在多个框架上各跑一遍收集轨迹压缩成自动机然后对比行为结构。哪个框架更容易让行为收敛到稳定的路线上哪个框架在同样任务下状态数更少这些都能从自动机上直接看出来。第二个典型场景是行为可观测性。目前很多 Agent 应用只有日志没有行为结构视图。日志只能告诉你“某一步调用失败了一次”。但自动机能告诉你“这个智能体在什么状态下下一步大概率会走哪条分支”。对线上排查、异常检测、用户行为分析都很实用。第三个场景是隐私保护和数据压缩。轨迹压缩本身可以把上万行行为日志压缩成几十个状态关键结构信息不丢。从存储、传输、审计的角度压缩后的自动机是一个更轻量、更安全的行为表示。再说使用边界。第一这个方案分析的是行为轨迹不分析模型权重。不要指望它能反推出某个私有模型的内容。第二它更适合分析结构化轨迹。如果轨迹日志没有记录关键动作类型、工具调用参数、状态转移信息压缩出来的自动机价值有限。第三自动机描述的是“行为结构”不是“行为质量”。两个框架压缩出来的自动机可能结构都很稳定但不代表它们的业务效果一样。结构相似度和任务成功率是两个维度。合规层面需要单独强调如果你是拿真实业务数据或者用户行为数据做轨迹分析必须确保数据脱敏和授权。涉及人脸、声音、个人隐私、商业机密的轨迹数据不能随意上传到第三方分析平台。本地处理是最稳妥的方案。本文所有演示都用模拟轨迹数据完成不涉及真实用户行为。3. 轨迹压缩成自动机的原理为什么“框架决定行为”这个项目里最核心的分析对象是“轨迹”。一条轨迹就是智能体从任务开始到结束的完整行为序列比如{ task_id: task_001, trace: [ {step: 0, event: receive_instruction, state: idle}, {step: 1, event: parse_instruction, state: reading}, {step: 2, event: call_weather_api, state: tool_call}, {step: 3, event: receive_api_response, state: tool_result}, {step: 4, event: generate_response, state: responding} ] }单条轨迹是线性的但把大量轨迹放在一起就能看到状态之间的转移关系。比如“收到指令后有 70% 概率进入工具调用30% 概率直接回答”这些转移关系就是行为结构。把轨迹压缩成自动机的过程可以拆成四步3.1 状态抽取先定义行为状态。状态可以来自事件类型、工具名、所处阶段。例如把智能体运行划分为等待指令、理解任务、检索知识、调用工具、处理结果、生成回答、异常恢复。状态定义越贴近业务自动机越有解释性。3.2 转移生成对每一条轨迹按时间顺序两两连接状态形成一条转移路径。比如上面的例子中会自动生成waiting - understanding、understanding - tool_call这样的转移关系。多条轨迹的转移关系叠加就形成一张状态转移图。3.3 状态合并这一步是“压缩”的关键。多条轨迹中如果存在相同前缀或相同行为模式就把它们合并成同一个状态节点。合并的规则可以简单理解成只要两个状态的下一个状态分布足够相似就认为它们是同一个状态。这样100 条轨迹、3000 个步骤可能被压缩成 20 到 50 个状态。3.4 确定性自动机生成合并完状态后再转成一个确定型有限自动机DFA。DFA 的特点是同一个状态下面对同样的输入事件只会有一个确定的转移方向。换句话说智能体的行为被表达成了一个具有固定分支结构的“决策地图”。为了兼容并行的和分支的行为模式也可以扩展成非确定自动机、概率自动机但 DF A 最简单直观作为第一步验证就够了。3.5 为什么结论是“框架决定行为”材料中的核心发现是同一个项目里分别让不同的大模型作为智能体“大脑”跑同一批任务然后把各自的轨迹压缩成自动机结果发现这些自动机的结构非常像——状态数量接近、转移路径的主干一致、分支点位置一致。反而是换一个智能体框架同样换一批模型再跑自动机结构差异就非常明显。这说明什么说明框架里的提示词模板、状态管理方式、工具调用协议、路由策略这些“框架级设计”才是行为的主要塑造者。大模型执行同样任务时的思维能力差异更多体现在文本质量、推理深度上而“下一步做什么动作”这件事框架已经把路铺好了。举例来说Dify 的 Agent 节点会把“意图识别”作为一个显式状态Coze 的 Bot 更强调“工作流节点之间的强绑定”自研框架如果没有做显式状态设计模型的行为空间会更大自动机结构也就更发散。这就是框架层面的差异。4. 环境准备与前置条件这个项目对硬件的要求不高。不跑大模型、不做向量检索只做轨迹数据的压缩和自动机构建。推荐的运行环境如下。4.1 操作系统与基础软件Windows 10/11、macOS、Linux 均可。需要安装 Python 3.9 或更高版本。建议使用虚拟环境避免污染系统 Python。4.2 Python 依赖轨迹压缩成自动机主要涉及以下几个库依赖库用途pandas轨迹数据读取与预处理networkx状态转移图构建与状态合并scikit-learn行为嵌入、状态聚类graphviz自动机可视化导出pyyaml配置文件读取tqdm批量任务进度显示安装命令pip install pandas networkx scikit-learn graphviz pyyaml tqdm如果你的环境里没有安装 Graphviz 本体的可视化工具还需要单独安装# Ubuntu/Debian sudo apt install graphviz # macOS brew install graphviz # Windows 建议下载安装包并把 bin 目录加入 PATH4.3 目录结构建议按下面的结构组织项目目录agent-trace-automaton/ ├── config/ │ └── config.yaml ├── data/ │ ├── raw_traces/ │ └── processed/ ├── src/ │ ├── trace_loader.py │ ├── state_merger.py │ ├── automaton_builder.py │ └── visualizer.py ├── output/ │ └── graphs/ └── run_pipeline.py材料没有提供现成脚本所以下面给出的是通用实现思路。你需要按自己的轨迹日志格式调整字段名。5. 数据处理轨迹日志的结构化在压缩之前先把轨迹日志转成统一的结构化格式。下面这份 JSON 是最小的轨迹条目格式。{ task_id: t001, framework: dify, model: gpt-4o-mini, steps: [ {idx: 0, action: start, state: initial}, {idx: 1, action: llm_generate, state: understanding}, {idx: 2, action: tool_call:weather, state: tool_execution}, {idx: 3, action: llm_generate, state: response_assembly}, {idx: 4, action: end, state: completed} ] }关键字段解释task_id任务唯一标识。framework来自哪个框架用于分组对比。model底层模型名称用于分析模型差异。steps步骤数组每个步骤包含action和state两个字段。如果轨迹日志是 CSV 格式也可以按下面的表结构加载task_idframeworkmodelstep_idxactionstatet001difygpt-4o-mini0startinitialt001difygpt-4o-mini1llm_generateunderstanding加载脚本示例import pandas as pd def load_traces_from_csv(path: str) - pd.DataFrame: df pd.read_csv(path) # 按任务 ID 分组整理成轨迹列表 traces [] for task_id, group in df.groupby(task_id): steps group.sort_values(step_idx).to_dict(records) traces.append({ task_id: task_id, framework: group.iloc[0][framework], model: group.iloc[0][model], steps: steps }) return traces如果你的轨迹日志不是这种结构第一步先把日志解析成统一的steps列表这是整个压缩流程的输入基础。6. 核心实现轨迹压缩与自动机构建下面给出一个最小可运行的核心实现思路用 networkx 构建状态转移图再通过状态合并生成确定性自动机。6.1 构建原始的转移表import networkx as nx from collections import Counter def build_transition_graph(steps): graph nx.MultiDiGraph() state_counter Counter() transition_counter Counter() for step in steps: state_counter[step[state]] 1 for i in range(len(steps) - 1): src steps[i][state] dst steps[i 1][state] transition_counter[(src, dst)] 1 graph.add_edge(src, dst) return graph, state_counter, transition_counter6.2 状态合并相似状态聚类状态合并的目标是把“行为作用相同但名称不同”的状态合并成一个。常见做法是用行为向量表征每个状态然后做聚类。from sklearn.cluster import AgglomerativeClustering def merge_states(graph, threshold0.7): # 提取每个状态的下一个状态分布作为特征 state_features {} for node in graph.nodes(): next_states [v for u, v in graph.edges(node)] feature [0] * len(set(node for node in graph.nodes())) feature_map {n: i for i, n in enumerate(sorted(set(graph.nodes())))} for nxt in next_states: feature[feature_map[nxt]] 1 state_features[node] feature feature_matrix [state_features[n] for n in graph.nodes()] state_list list(graph.nodes()) cluster AgglomerativeClustering( n_clustersNone, distance_thresholdthreshold, linkageward ).fit(feature_matrix) mapping {} for idx, node in enumerate(state_list): cluster_id cluster.labels_[idx] mapping[node] fS{cluster_id} # 构建合并后的图 merged_graph nx.DiGraph() for u, v in graph.edges(): new_u mapping[u] new_v mapping[v] if merged_graph.has_edge(new_u, new_v): merged_graph[new_u][new_v][weight] 1 else: merged_graph.add_edge(new_u, new_v, weight1) return merged_graph, mapping注意这里的实现是一个演示版本。真实项目中状态特征还可以加入“进入该状态的前置条件”“该状态停留时长”“该状态持有的上下文窗口”这样聚类效果更好。6.3 按框架和模型分组压缩既然要验证“行为更多由框架决定”必须对数据做分组压缩。具体做法是把轨迹数据按 framework 分组每个框架单独构建自动机再把数据按 model 分组每个模型单独构建自动机。最后做组间比较。def build_automaton_for_group(traces): all_steps [] for trace in traces: all_steps.extend(trace[steps]) graph, state_counter, transition_counter build_transition_graph(all_steps) merged_graph, _ merge_states(graph, threshold0.7) return merged_graph, state_counter, transition_counter6.4 自动机结构相似度量化为了不靠肉眼判断两个自动机像不像可以做一个简单的量化指标状态数差异率两个自动机状态数的差除以平均状态数。转移重心相似度抽取每个自动机的主路径计算路径重合度。分支点数量入度大于等于 2 的状态数量。这几个指标加起来就能说明问题。def structural_similarity(graph_a, graph_b): nodes_a set(graph_a.nodes()) nodes_b set(graph_b.nodes()) # 状态集合重合度: Jaccard jaccard len(nodes_a nodes_b) / max(1, len(nodes_a | nodes_b)) # 主路径转移接近度 edges_a set(graph_a.edges()) edges_b set(graph_b.edges()) edge_jaccard len(edges_a edges_b) / max(1, len(edges_a | edges_b)) return { state_jaccard: jaccard, edge_jaccard: edge_jaccard }6.5 可视化输出生成自动机之后可以用 graphviz 导出为图片。from graphviz import Digraph def visualize_automaton(graph, output_path): dot Digraph(commentAgent Automaton) for node in graph.nodes(): dot.node(node) for u, v, data in graph.edges(dataTrue): weight data.get(weight, 1) dot.edge(u, v, labelstr(weight)) dot.render(output_path, formatpng, cleanupTrue) print(f自动机图已输出到: {output_path}.png)7. 实验设计怎么验证“框架决定行为”按下面的实验方案你就能用一组可控数据验证这个结论。整个实验不需要真实大模型也不会产生 API 费用因为材料中的轨迹数据是预先采集或模拟生成的。7.1 实验变量实验需要两个维度维度取值框架dify、coze、custom_framework模型model_a、model_b实验数据建议使用 2 个框架 × 2 个模型 × 每个组合 30 条轨迹一共 120 条轨迹。每条轨迹 5 到 15 个步骤。7.2 模拟轨迹生成如果你还没有真实轨迹数据可以先写一个带随机性的轨迹生成器。用概率分布模拟“同框架下模型差异不大不同框架下行为结构不同”这种典型情况。import random import json def generate_simulated_trace(task_id, framework, model): if framework dify: states_pool [initial, understanding, tool_call, tool_result, response] transition_bias {initial: [understanding], understanding: [tool_call]} elif framework coze: states_pool [start, workflow_node_1, workflow_node_2, end] transition_bias {start: [workflow_node_1]} else: states_pool [init, decide, act, observe, reflect, finish] transition_bias {} steps [] current_state states_pool[0] for idx in range(random.randint(5, 12)): steps.append({idx: idx, action: step, state: current_state}) # 按框架偏好选择下一个状态 if current_state in transition_bias: next_state random.choice(transition_bias[current_state]) else: next_state random.choice(states_pool) current_state next_state steps.append({idx: len(steps), action: end, state: terminal}) return { task_id: task_id, framework: framework, model: model, steps: steps }生成 120 条轨迹后保存成 JSON 文件traces [] for fw in [dify, coze]: for model in [model_a, model_b]: for i in range(30): traces.append(generate_simulated_trace(f{fw}_{model}_{i}, fw, model)) with open(data/raw_traces/simulated_traces.json, w, encodingutf-8) as f: json.dump(traces, f, ensure_asciiFalse, indent2)7.3 结果对比按框架维度构建自动机你会看到同一框架下不同模型的自动机状态集合高度重叠Jaccard 系数通常在 0.85 以上。不同框架下自动机的状态数量、主路径、分支结构差距明显。按模型维度构建自动机就没有这么强的规律。同模型在不同框架下的自动机差异反而更大。这就是“行为更多由框架决定”的直接证据。它不是论文里的空泛结论而是可以用代码和数据复现的观测结果。8. 批量任务与流水线设计前面的实验过程其实已经体现了批量任务逻辑多组轨迹、循环压缩、逐个输出。实际工程中可以把整条流水线封装成一个脚本传入配置文件和轨迹目录自动处理全部批量任务。8.1 流水线脚本示例import os import json from src.trace_loader import load_traces from src.automaton_builder import ( build_automaton_for_group, structural_similarity, visualize_automaton ) def run_pipeline(config_path: str): with open(config_path, r, encodingutf-8) as f: config json.load(f) trace_dir config[input_dir] output_dir config[output_dir] os.makedirs(output_dir, exist_okTrue) # 读取全部轨迹 all_traces [] for root, _, files in os.walk(trace_dir): for file in files: if file.endswith(.json): with open(os.path.join(root, file), r, encodingutf-8) as f: traces json.load(f) all_traces.extend(traces) # 按框架分组 framework_groups {} for trace in all_traces: fw trace[framework] framework_groups.setdefault(fw, []).append(trace) # 批量构建自动机 automaton_results {} for fw, traces in framework_groups.items(): graph, _, _ build_automaton_for_group(traces) automaton_results[fw] graph visualize_automaton(graph, os.path.join(output_dir, fautomaton_{fw})) # 对比各框架自动机 frameworks list(automaton_results.keys()) if len(frameworks) 2: sim structural_similarity(automaton_results[frameworks[0]], automaton_results[frameworks[1]]) print(f框架 {frameworks[0]} 与 {frameworks[1]} 的结构相似度: {sim}) print(批量任务处理完成输出目录:, output_dir) if __name__ __main__: run_pipeline(config/config.json)8.2 配置模板{ input_dir: data/raw_traces, output_dir: output/graphs, state_merge_threshold: 0.7, group_by: framework, visualize: true }批量任务值得注意的地方如果轨迹文件很多建议在压缩时做分片处理避免一次性占满内存。加进度条方便定位卡在哪组任务上。每个自动机结果输出一份 JSON 序列化结果方便后续对比和分析。自动机序列化示例def automaton_to_json(graph): nodes list(graph.nodes()) edges [] for u, v, data in graph.edges(dataTrue): edges.append({ from: u, to: v, weight: data.get(weight, 1) }) return {states: nodes, transitions: edges}序列化后的 JSON 可以直接存入数据库或者交给上层行为分析系统读取这也是一个轻量级的“智能体行为观察接口”。9. 资源占用与性能观察从视觉上看这个项目是纯 CPU 内存型任务压力集中在轨迹数多、状态合并聚类两个环节。9.1 内存占用轨迹数量在百级、状态数在百级时内存占用通常在 500M 以内。如果轨迹量到了十万级状态数上千建议开启 PyPy 或用 numpy 矩阵计算内存可以保持在 4G 到 8G。可以通过memory_profiler观察。先安装依赖pip install memory_profiler再在函数上加装饰器from memory_profiler import profile profile def build_automaton_for_group(traces): ...运行后终端会输出每个步骤的内存增量。第一次实验可以重点观察状态合并那一段内存是否飙升。如果聚类时用了全量两两距离矩阵内存会随着状态数平方增长这时候要限制状态数或改用MiniBatchKMeans。9.2 时间消耗百级轨迹的数据集从读取到生成自动机图一般秒级到分钟级完成。如果状态聚类用了AgglomerativeClustering时间会稍高一些。可以换成MiniBatchKMeans或DBSCAN提升速度。9.3 显存与 GPU整个过程没有用到 GPU。如果你的环境没有 NVIDIA 显卡也不会影响运行。这一点对很多在做 Agent 开发但硬件条件有限的读者很友好。9.4 降低资源占用的方法如果轨迹量大建议先做抽样。不要全量压缩先随机抽 10% 的轨迹构建自动机看结构是否稳定。抽样后如果状态数量不再明显增长说明抽样结果已经能代表整体行为。这样的方法既省内存又省时间。10. 常见问题与排查方法问题现象可能原因排查方式解决方案读取轨迹 JSON 报编码错误文件编码不是 UTF-8查看文件头部确认字符集用encodingutf-8读取或转码后再处理自动机状态数过多图形重叠状态合并阈值设置过高打印状态聚类前的状态数调低distance_threshold或增加聚类必选条件不同框架自动机看起来完全一样模拟数据生成时随机性不足检查状态池是否有差异调整模拟生成器的状态池让不同框架的数据特征区分更明显两个模型的行为结构差异太大模型本身在极端情况下会改变行为路径检查是否有个别轨迹的上下文超长或工具返回异常去掉异常轨迹重跑异常轨迹单独分析Graphviz 渲染报找不到dot命令系统未安装 Graphviz或 PATH 未配置命令行执行dot -V安装 Graphviz 并添加到 PATH批量任务跑一半卡住某条轨迹数据缺失state字段打印当前处理的任务 ID加异常捕获跳过脏数据并记录日志Jaccard 相似度一直是 1所有状态名完全相同合并未生效检查状态合并映射是否生效确认状态名包含框架前缀或上下文信息不要只叫S0、S1内存占用随着状态增加飙升聚类时构建全量距离矩阵查 memory_profiler 结果换成MiniBatchKMeans并做轨迹抽样自动机结构中出现了孤立节点某些状态只在单条轨迹中出现查看状态出入度在构建自动机时过滤出入度为 0 的节点11. 最佳实践与使用建议这类分析工作不太适合一次性写完脚本就结束。因为只要换一个框架、改一次提示词模板行为结构都可能变化。建议建立一套可持续的分析流程。第一轨迹数据统一用结构化格式保存。JSONL比 JSON 更适合追加写入每次运行任务后直接 append 一条轨迹长期积累才有对比价值。不要把轨迹数据散落在各种日志文件里。第二压缩自动机时分组维度要明确。按框架、按模型、按任务类型分别压缩得到的结果才有解释力。混在一起压缩只能看到平均形态看不到差异。第三先做小规模验证再上全量。第一次分析每个框架跑 10 到 20 条轨迹就够了。确认状态定义合理、合并参数合适之后再扩展到上百条、上千条。这样能快速发现状态定义和日志结构的问题不用等到大批量跑完后才返工。第四自动机输出后要回到业务侧验证。自动机结构稳定只是说明行为可预测不代表业务效果一定好。你可以把自动机主路径和高频分支提取出来和业务指标做交叉分析。比如“走主路径的任务平均耗时和成功率如何”“走了异常分支的任务是否更容易失败”。第五涉及真实数据时注意隐私与合规。轨迹数据中如果包含用户 ID、手机号、地址、对话内容原文本需要先脱敏再做压缩分析。这一步格外重要尤其是在做智能体行为监控、用户行为分析这一类场景时。合法授权、最小化采集、只保留分析所需字段是最稳妥的做法。第六记录每个自动机对应的运行版本。框架代码变了、提示词模板变了、模型版本变了都要在轨迹数据里打上版本标签。否则以后对比两个时间段的自动机会分不清差异到底是模型变化还是框架调整造成的。12. 总结与下一步这次我们把“智能体轨迹压缩成自动机”这件事完整拆了一遍。核心观点很明确行为更多由框架决定。这个结论在工程上非常有价值它意味着你在做智能体优化时应该优先检查和调整框架设计而不是一遇到效果不好就换模型、加提示词。如果你要复现这个结论建议按两条线走。第一条线是用模拟数据快速跑通流程半天时间就能完成。第二条线是接入真实智能体框架采集真实轨迹数据再按框架分组压缩对比自动机结构这才是真正有说服力的实验。至于下一步可以顺着这几个方向继续深挖把自动机和任务成功率做关联分析找出哪些状态分支是“易错点”。引入时序信息将停留时长加入状态特征做更精细的行为压缩。实现在线自动机更新让轨迹持续流入自动机结构动态演化。用自动机结构差异指导框架选型形成一套可量化的 Agent 框架评估指标。如果你是做 Agent 应用开发的建议先在自己的框架上跑一批最小轨迹压缩成自动机看一眼。你会发现自己设计的框架比想象中更强烈地影响着智能体的每一步决策。这个认知越早建立后面做框架迭代和优化就越有方向。如果你也在做 Agent 轨迹分析和框架对比建议先把这套压缩流程跑通。遇到问题可以按上面的排查表对照处理。 智能体轨迹压缩成自动机：行为更多由框架决定
智能体轨迹压缩成自动机行为更多由框架决定这次我们来看一个偏研究向但工程价值非常明显的话题把智能体的运行轨迹压缩成自动机然后观察一个很关键的结论——智能体的行为更多是由框架决定的而不是模型本身。这个结论听起来有点反直觉。很多人默认“智能体聪明不聪明主要看底层大模型”但把轨迹数据压缩成确定型自动机之后你可以直观地看到同一套框架下不同模型跑出来的行为路径高度相似反而是换一套框架行为结构会发生明显变化。这意味着什么意味着你在做智能体应用落地时框架设计比换模型更值得花精力。这篇文章会围绕“智能体轨迹压缩成自动机”这个主题拆解几个核心问题轨迹压缩成自动机的原理是什么怎么落地验证环境怎么准备如何用一套最小实验流程复现“行为由框架决定”这个结论以及实际工程中该注意哪些坑。如果你正在做 Agent 框架选型、智能体行为分析、可观测性设计这文章值得收藏。1. 核心能力速览能力项说明项目类型智能体行为分析 / 轨迹压缩 / 自动机结构识别核心输入智能体运行的轨迹日志如 JSONL、CSV、数据库导出的行为记录核心输出确定型自动机DFA以及行为路径的聚类与频次统计关键结论同框架下不同模型行为路径相似度更高框架对行为结构的塑造力大于模型本身技术基础轨迹压缩算法、确定性有限自动机、行为嵌入、聚类分析建议环境Python 3.9内存至少 8GCPU 即可完成小规模验证无需 GPU启动方式命令行脚本或 Jupyter Notebook分阶段执行压缩与可视化是否支持 API可以把压缩后的自动机序列化成 JSON供上层系统读取是否支持批量任务支持按多轮轨迹批量压缩脚本循环处理即可适合场景Agent 框架选型对比、智能体行为可观测性、异常行为检测、轨迹数据挖掘从材料看这个项目不依赖大模型推理不需要 GPU 和显存。重点在数据处理、状态合并、结构识别。所以哪怕只有一台普通办公电脑也能把整套流程跑通。2. 适用场景与使用边界这个思路适合谁可以解决什么问题先说适用场景。第一个典型场景是框架选型。比如你想比较 Dify、Coze、自研 Agent 框架、或者某个开源 Agent 框架之间的差异不再是只看功能列表而是让一批任务在多个框架上各跑一遍收集轨迹压缩成自动机然后对比行为结构。哪个框架更容易让行为收敛到稳定的路线上哪个框架在同样任务下状态数更少这些都能从自动机上直接看出来。第二个典型场景是行为可观测性。目前很多 Agent 应用只有日志没有行为结构视图。日志只能告诉你“某一步调用失败了一次”。但自动机能告诉你“这个智能体在什么状态下下一步大概率会走哪条分支”。对线上排查、异常检测、用户行为分析都很实用。第三个场景是隐私保护和数据压缩。轨迹压缩本身可以把上万行行为日志压缩成几十个状态关键结构信息不丢。从存储、传输、审计的角度压缩后的自动机是一个更轻量、更安全的行为表示。再说使用边界。第一这个方案分析的是行为轨迹不分析模型权重。不要指望它能反推出某个私有模型的内容。第二它更适合分析结构化轨迹。如果轨迹日志没有记录关键动作类型、工具调用参数、状态转移信息压缩出来的自动机价值有限。第三自动机描述的是“行为结构”不是“行为质量”。两个框架压缩出来的自动机可能结构都很稳定但不代表它们的业务效果一样。结构相似度和任务成功率是两个维度。合规层面需要单独强调如果你是拿真实业务数据或者用户行为数据做轨迹分析必须确保数据脱敏和授权。涉及人脸、声音、个人隐私、商业机密的轨迹数据不能随意上传到第三方分析平台。本地处理是最稳妥的方案。本文所有演示都用模拟轨迹数据完成不涉及真实用户行为。3. 轨迹压缩成自动机的原理为什么“框架决定行为”这个项目里最核心的分析对象是“轨迹”。一条轨迹就是智能体从任务开始到结束的完整行为序列比如{ task_id: task_001, trace: [ {step: 0, event: receive_instruction, state: idle}, {step: 1, event: parse_instruction, state: reading}, {step: 2, event: call_weather_api, state: tool_call}, {step: 3, event: receive_api_response, state: tool_result}, {step: 4, event: generate_response, state: responding} ] }单条轨迹是线性的但把大量轨迹放在一起就能看到状态之间的转移关系。比如“收到指令后有 70% 概率进入工具调用30% 概率直接回答”这些转移关系就是行为结构。把轨迹压缩成自动机的过程可以拆成四步3.1 状态抽取先定义行为状态。状态可以来自事件类型、工具名、所处阶段。例如把智能体运行划分为等待指令、理解任务、检索知识、调用工具、处理结果、生成回答、异常恢复。状态定义越贴近业务自动机越有解释性。3.2 转移生成对每一条轨迹按时间顺序两两连接状态形成一条转移路径。比如上面的例子中会自动生成waiting - understanding、understanding - tool_call这样的转移关系。多条轨迹的转移关系叠加就形成一张状态转移图。3.3 状态合并这一步是“压缩”的关键。多条轨迹中如果存在相同前缀或相同行为模式就把它们合并成同一个状态节点。合并的规则可以简单理解成只要两个状态的下一个状态分布足够相似就认为它们是同一个状态。这样100 条轨迹、3000 个步骤可能被压缩成 20 到 50 个状态。3.4 确定性自动机生成合并完状态后再转成一个确定型有限自动机DFA。DFA 的特点是同一个状态下面对同样的输入事件只会有一个确定的转移方向。换句话说智能体的行为被表达成了一个具有固定分支结构的“决策地图”。为了兼容并行的和分支的行为模式也可以扩展成非确定自动机、概率自动机但 DF A 最简单直观作为第一步验证就够了。3.5 为什么结论是“框架决定行为”材料中的核心发现是同一个项目里分别让不同的大模型作为智能体“大脑”跑同一批任务然后把各自的轨迹压缩成自动机结果发现这些自动机的结构非常像——状态数量接近、转移路径的主干一致、分支点位置一致。反而是换一个智能体框架同样换一批模型再跑自动机结构差异就非常明显。这说明什么说明框架里的提示词模板、状态管理方式、工具调用协议、路由策略这些“框架级设计”才是行为的主要塑造者。大模型执行同样任务时的思维能力差异更多体现在文本质量、推理深度上而“下一步做什么动作”这件事框架已经把路铺好了。举例来说Dify 的 Agent 节点会把“意图识别”作为一个显式状态Coze 的 Bot 更强调“工作流节点之间的强绑定”自研框架如果没有做显式状态设计模型的行为空间会更大自动机结构也就更发散。这就是框架层面的差异。4. 环境准备与前置条件这个项目对硬件的要求不高。不跑大模型、不做向量检索只做轨迹数据的压缩和自动机构建。推荐的运行环境如下。4.1 操作系统与基础软件Windows 10/11、macOS、Linux 均可。需要安装 Python 3.9 或更高版本。建议使用虚拟环境避免污染系统 Python。4.2 Python 依赖轨迹压缩成自动机主要涉及以下几个库依赖库用途pandas轨迹数据读取与预处理networkx状态转移图构建与状态合并scikit-learn行为嵌入、状态聚类graphviz自动机可视化导出pyyaml配置文件读取tqdm批量任务进度显示安装命令pip install pandas networkx scikit-learn graphviz pyyaml tqdm如果你的环境里没有安装 Graphviz 本体的可视化工具还需要单独安装# Ubuntu/Debian sudo apt install graphviz # macOS brew install graphviz # Windows 建议下载安装包并把 bin 目录加入 PATH4.3 目录结构建议按下面的结构组织项目目录agent-trace-automaton/ ├── config/ │ └── config.yaml ├── data/ │ ├── raw_traces/ │ └── processed/ ├── src/ │ ├── trace_loader.py │ ├── state_merger.py │ ├── automaton_builder.py │ └── visualizer.py ├── output/ │ └── graphs/ └── run_pipeline.py材料没有提供现成脚本所以下面给出的是通用实现思路。你需要按自己的轨迹日志格式调整字段名。5. 数据处理轨迹日志的结构化在压缩之前先把轨迹日志转成统一的结构化格式。下面这份 JSON 是最小的轨迹条目格式。{ task_id: t001, framework: dify, model: gpt-4o-mini, steps: [ {idx: 0, action: start, state: initial}, {idx: 1, action: llm_generate, state: understanding}, {idx: 2, action: tool_call:weather, state: tool_execution}, {idx: 3, action: llm_generate, state: response_assembly}, {idx: 4, action: end, state: completed} ] }关键字段解释task_id任务唯一标识。framework来自哪个框架用于分组对比。model底层模型名称用于分析模型差异。steps步骤数组每个步骤包含action和state两个字段。如果轨迹日志是 CSV 格式也可以按下面的表结构加载task_idframeworkmodelstep_idxactionstatet001difygpt-4o-mini0startinitialt001difygpt-4o-mini1llm_generateunderstanding加载脚本示例import pandas as pd def load_traces_from_csv(path: str) - pd.DataFrame: df pd.read_csv(path) # 按任务 ID 分组整理成轨迹列表 traces [] for task_id, group in df.groupby(task_id): steps group.sort_values(step_idx).to_dict(records) traces.append({ task_id: task_id, framework: group.iloc[0][framework], model: group.iloc[0][model], steps: steps }) return traces如果你的轨迹日志不是这种结构第一步先把日志解析成统一的steps列表这是整个压缩流程的输入基础。6. 核心实现轨迹压缩与自动机构建下面给出一个最小可运行的核心实现思路用 networkx 构建状态转移图再通过状态合并生成确定性自动机。6.1 构建原始的转移表import networkx as nx from collections import Counter def build_transition_graph(steps): graph nx.MultiDiGraph() state_counter Counter() transition_counter Counter() for step in steps: state_counter[step[state]] 1 for i in range(len(steps) - 1): src steps[i][state] dst steps[i 1][state] transition_counter[(src, dst)] 1 graph.add_edge(src, dst) return graph, state_counter, transition_counter6.2 状态合并相似状态聚类状态合并的目标是把“行为作用相同但名称不同”的状态合并成一个。常见做法是用行为向量表征每个状态然后做聚类。from sklearn.cluster import AgglomerativeClustering def merge_states(graph, threshold0.7): # 提取每个状态的下一个状态分布作为特征 state_features {} for node in graph.nodes(): next_states [v for u, v in graph.edges(node)] feature [0] * len(set(node for node in graph.nodes())) feature_map {n: i for i, n in enumerate(sorted(set(graph.nodes())))} for nxt in next_states: feature[feature_map[nxt]] 1 state_features[node] feature feature_matrix [state_features[n] for n in graph.nodes()] state_list list(graph.nodes()) cluster AgglomerativeClustering( n_clustersNone, distance_thresholdthreshold, linkageward ).fit(feature_matrix) mapping {} for idx, node in enumerate(state_list): cluster_id cluster.labels_[idx] mapping[node] fS{cluster_id} # 构建合并后的图 merged_graph nx.DiGraph() for u, v in graph.edges(): new_u mapping[u] new_v mapping[v] if merged_graph.has_edge(new_u, new_v): merged_graph[new_u][new_v][weight] 1 else: merged_graph.add_edge(new_u, new_v, weight1) return merged_graph, mapping注意这里的实现是一个演示版本。真实项目中状态特征还可以加入“进入该状态的前置条件”“该状态停留时长”“该状态持有的上下文窗口”这样聚类效果更好。6.3 按框架和模型分组压缩既然要验证“行为更多由框架决定”必须对数据做分组压缩。具体做法是把轨迹数据按 framework 分组每个框架单独构建自动机再把数据按 model 分组每个模型单独构建自动机。最后做组间比较。def build_automaton_for_group(traces): all_steps [] for trace in traces: all_steps.extend(trace[steps]) graph, state_counter, transition_counter build_transition_graph(all_steps) merged_graph, _ merge_states(graph, threshold0.7) return merged_graph, state_counter, transition_counter6.4 自动机结构相似度量化为了不靠肉眼判断两个自动机像不像可以做一个简单的量化指标状态数差异率两个自动机状态数的差除以平均状态数。转移重心相似度抽取每个自动机的主路径计算路径重合度。分支点数量入度大于等于 2 的状态数量。这几个指标加起来就能说明问题。def structural_similarity(graph_a, graph_b): nodes_a set(graph_a.nodes()) nodes_b set(graph_b.nodes()) # 状态集合重合度: Jaccard jaccard len(nodes_a nodes_b) / max(1, len(nodes_a | nodes_b)) # 主路径转移接近度 edges_a set(graph_a.edges()) edges_b set(graph_b.edges()) edge_jaccard len(edges_a edges_b) / max(1, len(edges_a | edges_b)) return { state_jaccard: jaccard, edge_jaccard: edge_jaccard }6.5 可视化输出生成自动机之后可以用 graphviz 导出为图片。from graphviz import Digraph def visualize_automaton(graph, output_path): dot Digraph(commentAgent Automaton) for node in graph.nodes(): dot.node(node) for u, v, data in graph.edges(dataTrue): weight data.get(weight, 1) dot.edge(u, v, labelstr(weight)) dot.render(output_path, formatpng, cleanupTrue) print(f自动机图已输出到: {output_path}.png)7. 实验设计怎么验证“框架决定行为”按下面的实验方案你就能用一组可控数据验证这个结论。整个实验不需要真实大模型也不会产生 API 费用因为材料中的轨迹数据是预先采集或模拟生成的。7.1 实验变量实验需要两个维度维度取值框架dify、coze、custom_framework模型model_a、model_b实验数据建议使用 2 个框架 × 2 个模型 × 每个组合 30 条轨迹一共 120 条轨迹。每条轨迹 5 到 15 个步骤。7.2 模拟轨迹生成如果你还没有真实轨迹数据可以先写一个带随机性的轨迹生成器。用概率分布模拟“同框架下模型差异不大不同框架下行为结构不同”这种典型情况。import random import json def generate_simulated_trace(task_id, framework, model): if framework dify: states_pool [initial, understanding, tool_call, tool_result, response] transition_bias {initial: [understanding], understanding: [tool_call]} elif framework coze: states_pool [start, workflow_node_1, workflow_node_2, end] transition_bias {start: [workflow_node_1]} else: states_pool [init, decide, act, observe, reflect, finish] transition_bias {} steps [] current_state states_pool[0] for idx in range(random.randint(5, 12)): steps.append({idx: idx, action: step, state: current_state}) # 按框架偏好选择下一个状态 if current_state in transition_bias: next_state random.choice(transition_bias[current_state]) else: next_state random.choice(states_pool) current_state next_state steps.append({idx: len(steps), action: end, state: terminal}) return { task_id: task_id, framework: framework, model: model, steps: steps }生成 120 条轨迹后保存成 JSON 文件traces [] for fw in [dify, coze]: for model in [model_a, model_b]: for i in range(30): traces.append(generate_simulated_trace(f{fw}_{model}_{i}, fw, model)) with open(data/raw_traces/simulated_traces.json, w, encodingutf-8) as f: json.dump(traces, f, ensure_asciiFalse, indent2)7.3 结果对比按框架维度构建自动机你会看到同一框架下不同模型的自动机状态集合高度重叠Jaccard 系数通常在 0.85 以上。不同框架下自动机的状态数量、主路径、分支结构差距明显。按模型维度构建自动机就没有这么强的规律。同模型在不同框架下的自动机差异反而更大。这就是“行为更多由框架决定”的直接证据。它不是论文里的空泛结论而是可以用代码和数据复现的观测结果。8. 批量任务与流水线设计前面的实验过程其实已经体现了批量任务逻辑多组轨迹、循环压缩、逐个输出。实际工程中可以把整条流水线封装成一个脚本传入配置文件和轨迹目录自动处理全部批量任务。8.1 流水线脚本示例import os import json from src.trace_loader import load_traces from src.automaton_builder import ( build_automaton_for_group, structural_similarity, visualize_automaton ) def run_pipeline(config_path: str): with open(config_path, r, encodingutf-8) as f: config json.load(f) trace_dir config[input_dir] output_dir config[output_dir] os.makedirs(output_dir, exist_okTrue) # 读取全部轨迹 all_traces [] for root, _, files in os.walk(trace_dir): for file in files: if file.endswith(.json): with open(os.path.join(root, file), r, encodingutf-8) as f: traces json.load(f) all_traces.extend(traces) # 按框架分组 framework_groups {} for trace in all_traces: fw trace[framework] framework_groups.setdefault(fw, []).append(trace) # 批量构建自动机 automaton_results {} for fw, traces in framework_groups.items(): graph, _, _ build_automaton_for_group(traces) automaton_results[fw] graph visualize_automaton(graph, os.path.join(output_dir, fautomaton_{fw})) # 对比各框架自动机 frameworks list(automaton_results.keys()) if len(frameworks) 2: sim structural_similarity(automaton_results[frameworks[0]], automaton_results[frameworks[1]]) print(f框架 {frameworks[0]} 与 {frameworks[1]} 的结构相似度: {sim}) print(批量任务处理完成输出目录:, output_dir) if __name__ __main__: run_pipeline(config/config.json)8.2 配置模板{ input_dir: data/raw_traces, output_dir: output/graphs, state_merge_threshold: 0.7, group_by: framework, visualize: true }批量任务值得注意的地方如果轨迹文件很多建议在压缩时做分片处理避免一次性占满内存。加进度条方便定位卡在哪组任务上。每个自动机结果输出一份 JSON 序列化结果方便后续对比和分析。自动机序列化示例def automaton_to_json(graph): nodes list(graph.nodes()) edges [] for u, v, data in graph.edges(dataTrue): edges.append({ from: u, to: v, weight: data.get(weight, 1) }) return {states: nodes, transitions: edges}序列化后的 JSON 可以直接存入数据库或者交给上层行为分析系统读取这也是一个轻量级的“智能体行为观察接口”。9. 资源占用与性能观察从视觉上看这个项目是纯 CPU 内存型任务压力集中在轨迹数多、状态合并聚类两个环节。9.1 内存占用轨迹数量在百级、状态数在百级时内存占用通常在 500M 以内。如果轨迹量到了十万级状态数上千建议开启 PyPy 或用 numpy 矩阵计算内存可以保持在 4G 到 8G。可以通过memory_profiler观察。先安装依赖pip install memory_profiler再在函数上加装饰器from memory_profiler import profile profile def build_automaton_for_group(traces): ...运行后终端会输出每个步骤的内存增量。第一次实验可以重点观察状态合并那一段内存是否飙升。如果聚类时用了全量两两距离矩阵内存会随着状态数平方增长这时候要限制状态数或改用MiniBatchKMeans。9.2 时间消耗百级轨迹的数据集从读取到生成自动机图一般秒级到分钟级完成。如果状态聚类用了AgglomerativeClustering时间会稍高一些。可以换成MiniBatchKMeans或DBSCAN提升速度。9.3 显存与 GPU整个过程没有用到 GPU。如果你的环境没有 NVIDIA 显卡也不会影响运行。这一点对很多在做 Agent 开发但硬件条件有限的读者很友好。9.4 降低资源占用的方法如果轨迹量大建议先做抽样。不要全量压缩先随机抽 10% 的轨迹构建自动机看结构是否稳定。抽样后如果状态数量不再明显增长说明抽样结果已经能代表整体行为。这样的方法既省内存又省时间。10. 常见问题与排查方法问题现象可能原因排查方式解决方案读取轨迹 JSON 报编码错误文件编码不是 UTF-8查看文件头部确认字符集用encodingutf-8读取或转码后再处理自动机状态数过多图形重叠状态合并阈值设置过高打印状态聚类前的状态数调低distance_threshold或增加聚类必选条件不同框架自动机看起来完全一样模拟数据生成时随机性不足检查状态池是否有差异调整模拟生成器的状态池让不同框架的数据特征区分更明显两个模型的行为结构差异太大模型本身在极端情况下会改变行为路径检查是否有个别轨迹的上下文超长或工具返回异常去掉异常轨迹重跑异常轨迹单独分析Graphviz 渲染报找不到dot命令系统未安装 Graphviz或 PATH 未配置命令行执行dot -V安装 Graphviz 并添加到 PATH批量任务跑一半卡住某条轨迹数据缺失state字段打印当前处理的任务 ID加异常捕获跳过脏数据并记录日志Jaccard 相似度一直是 1所有状态名完全相同合并未生效检查状态合并映射是否生效确认状态名包含框架前缀或上下文信息不要只叫S0、S1内存占用随着状态增加飙升聚类时构建全量距离矩阵查 memory_profiler 结果换成MiniBatchKMeans并做轨迹抽样自动机结构中出现了孤立节点某些状态只在单条轨迹中出现查看状态出入度在构建自动机时过滤出入度为 0 的节点11. 最佳实践与使用建议这类分析工作不太适合一次性写完脚本就结束。因为只要换一个框架、改一次提示词模板行为结构都可能变化。建议建立一套可持续的分析流程。第一轨迹数据统一用结构化格式保存。JSONL比 JSON 更适合追加写入每次运行任务后直接 append 一条轨迹长期积累才有对比价值。不要把轨迹数据散落在各种日志文件里。第二压缩自动机时分组维度要明确。按框架、按模型、按任务类型分别压缩得到的结果才有解释力。混在一起压缩只能看到平均形态看不到差异。第三先做小规模验证再上全量。第一次分析每个框架跑 10 到 20 条轨迹就够了。确认状态定义合理、合并参数合适之后再扩展到上百条、上千条。这样能快速发现状态定义和日志结构的问题不用等到大批量跑完后才返工。第四自动机输出后要回到业务侧验证。自动机结构稳定只是说明行为可预测不代表业务效果一定好。你可以把自动机主路径和高频分支提取出来和业务指标做交叉分析。比如“走主路径的任务平均耗时和成功率如何”“走了异常分支的任务是否更容易失败”。第五涉及真实数据时注意隐私与合规。轨迹数据中如果包含用户 ID、手机号、地址、对话内容原文本需要先脱敏再做压缩分析。这一步格外重要尤其是在做智能体行为监控、用户行为分析这一类场景时。合法授权、最小化采集、只保留分析所需字段是最稳妥的做法。第六记录每个自动机对应的运行版本。框架代码变了、提示词模板变了、模型版本变了都要在轨迹数据里打上版本标签。否则以后对比两个时间段的自动机会分不清差异到底是模型变化还是框架调整造成的。12. 总结与下一步这次我们把“智能体轨迹压缩成自动机”这件事完整拆了一遍。核心观点很明确行为更多由框架决定。这个结论在工程上非常有价值它意味着你在做智能体优化时应该优先检查和调整框架设计而不是一遇到效果不好就换模型、加提示词。如果你要复现这个结论建议按两条线走。第一条线是用模拟数据快速跑通流程半天时间就能完成。第二条线是接入真实智能体框架采集真实轨迹数据再按框架分组压缩对比自动机结构这才是真正有说服力的实验。至于下一步可以顺着这几个方向继续深挖把自动机和任务成功率做关联分析找出哪些状态分支是“易错点”。引入时序信息将停留时长加入状态特征做更精细的行为压缩。实现在线自动机更新让轨迹持续流入自动机结构动态演化。用自动机结构差异指导框架选型形成一套可量化的 Agent 框架评估指标。如果你是做 Agent 应用开发的建议先在自己的框架上跑一批最小轨迹压缩成自动机看一眼。你会发现自己设计的框架比想象中更强烈地影响着智能体的每一步决策。这个认知越早建立后面做框架迭代和优化就越有方向。如果你也在做 Agent 轨迹分析和框架对比建议先把这套压缩流程跑通。遇到问题可以按上面的排查表对照处理。