★ FEATURED ARTICLE 1. 这不是“选框架”而是重新定义你和大模型的协作关系“AI Agent 架构怎么选”——这句话在最近三个月里我至少被问了二十七次。提问者身份五花八门某高校实验室带研究生做智能体课题的导师、某ToB SaaS公司刚接手AI中台建设的架构师、还有几位从后端转岗过来、手握Spring Boot十年但第一次面对tool_call返回JSON的工程师。他们真正想问的从来不是“LangChain、LlamaIndex、Semantic Kernel哪个好”而是“我手头这个报销单自动核验多部门协同审批的流程到底该用一个函数调用就搞定还是得搭一套带记忆、规划、工具路由、失败重试、可观测性的运行时”这个问题背后藏着一个被严重低估的事实LLM调用本身早已不是技术瓶颈真正的分水岭在于“调用之后发生了什么”。一次/v1/chat/completions请求发出去模型返回了{tool_calls: [...]}接下来呢是直接把tool_calls里的参数硬编码进requests.post()还是让系统自动识别这是财务API、校验权限、注入上下文、重试超时、记录trace、失败时降级为人工兜底这些动作加起来才构成一个可交付、可运维、可审计的AI Agent。所以本文不谈“框架对比评测”也不列“十大Agent开源项目”。我要带你走一遍真实项目落地中最常卡壳的那条路径从你在Jupyter里敲下第一行response client.chat.completions.create(...)开始到最终上线一个能处理3000日均工单、平均响应延迟2.4s、错误率0.7%的生产级Harness Runtime——中间每一步的技术取舍、踩坑现场、参数依据全部摊开讲。你会看到所谓“架构选择”本质是在确定性与灵活性、开发速度与长期维护成本、单点性能与系统韧性之间做一连串不可回避的权衡。而这些权衡的答案藏在你的业务SLA里藏在你的团队技能树里更藏在你对“失败”的定义里。2. 内容整体设计与思路拆解为什么必须放弃“调用即完成”的思维惯性2.1 从单次调用到Runtime三层能力跃迁的本质很多团队卡在第一步是因为没意识到LLM集成存在明确的能力断层。我把整个演进划分为三个物理层级每一层都对应一组必须显式解决的问题L1Raw LLM Call原始调用层典型场景在内部知识库问答Bot里用户问“差旅报销标准是多少”后端拼接system prompt RAG检索结果 用户query调一次API返回纯文本答案。✅ 优势5分钟可跑通无额外依赖适合POC验证。❌ 死穴无法处理需要多步操作的任务如“查张三上月报销记录→比对发票金额→触发财务复核→通知申请人”无法应对模型“说错话”比如把reimburse_idABC123错写成ABC12S所有状态全靠HTTP短连接维持无上下文延续。L2Orchestrated Agent编排代理层典型场景客服工单分类系统。用户上传一张模糊的发票照片Agent需先调OCR服务提取文字再调NLP模型识别票据类型再根据类型路由至不同审核规则引擎最后生成结构化工单。✅ 优势支持多步骤、多工具、有条件分支可引入简单记忆如缓存前一轮OCR结果错误可局部重试。❌ 死穴工具调用逻辑散落在各处有的写在prompt里有的在if-else里缺乏统一的执行生命周期管理比如工具超时后是否降级失败后是否记录到告警平台调试困难——你永远不知道是OCR识别错了还是路由规则写漏了。L3Harness Runtime运行时层典型场景某金融公司信贷审批Agent。需对接核心银行系统强一致性要求、征信查询API高延迟、内部风控模型私有GPU集群。要求单次审批链路耗时≤8sP95工具调用失败自动切换备用通道所有决策留痕供监管审计支持按客户ID实时追踪全链路状态。✅ 优势提供标准化的执行基座调度、内存、工具注册、可观测性、安全沙箱将业务逻辑与基础设施解耦天然支持灰度发布、AB测试、熔断降级。❌ 死穴初期投入大需要定义清晰的组件契约如工具描述必须含input_schema和output_schema对团队工程能力要求陡增。提示没有“最好”的架构只有“最不痛”的架构。我们曾帮一家电商客户评估方案他们日均订单审核量仅200单但要求100%准确率。最终选择L2层自研轻量编排器约800行Python而非接入LangChain——因为LangChain的默认重试策略会重发整个思考链路导致重复扣减库存。而他们的业务痛点根本不在“多工具协调”而在“如何确保工具调用原子性”。这就是典型的需求倒逼架构。2.2 为什么“Harness Runtime”正在成为事实标准过去一年我深度参与了6个跨行业Agent项目发现一个强相关现象当项目进入第二阶段即从“能跑”到“敢用”90%的团队会自发构建某种形式的Runtime。这不是技术炫技而是由三类刚性需求驱动的必然结果可观测性刚需某医疗客户上线初版Agent后发现30%的问诊建议被医生手动覆盖。但没人知道原因——是模型对药品禁忌症理解偏差还是RAG召回的指南文档过期抑或工具调用时传入了错误的患者ID没有统一trace ID、没有工具调用耗时分布、没有prompt版本标记这种问题根本无法归因。Harness Runtime通过强制注入span_id、记录tool_input_hash、绑定prompt_template_version让每个决策节点可追溯。安全与合规硬约束某政务系统要求所有对外API调用必须经由统一网关鉴权并记录完整请求/响应报文。如果工具调用分散在20个Python文件里审计方一句“请证明所有外部调用都经过了网关”就能让整个项目停摆。Runtime层将工具抽象为注册中心内的标准接口网关拦截、脱敏、审计全部下沉到基础设施层。长周期维护成本某制造业客户最初用LangChain Chain实现设备故障诊断Agent半年后新增5种传感器数据源。每次加新工具都要改prompt模板、调LLMChain参数、修output_parser。而迁移到自研Runtime后只需在tools/目录下新增一个vibration_analyzer.py声明其input_schema和auth_type系统自动完成注册、鉴权、超时配置。迭代效率提升3倍以上。这解释了为什么像Microsoft的Semantic Kernel、LangChain的LangGraph、以及新兴的LlamaIndex的Agent SDK都在快速收敛到相似的Runtime范式以“执行计划Plan”为核心用“工具注册表Tool Registry”解耦能力靠“内存抽象Memory Abstraction”维持状态借“可观测性钩子Observability Hooks”保障稳定。它们不是在竞争功能而是在争夺“Agent操作系统”的定义权。2.3 我们的技术选型决策树不看Star数只问这四个问题在具体落地前我给所有合作团队一张极简决策表。它不涉及任何代码只回答四个直击要害的问题。答案组合直接决定你该停在哪一层问题L1适用答案L2适用答案L3适用答案Q1你的任务是否必须包含≥2个外部系统交互如查数据库→调支付API→发邮件否纯推理/生成是但工具间无强依赖如并行查A/B/C系统是且存在严格执行顺序与状态传递如先验资→再授信→最后放款Q2能否接受单次失败导致整个任务中断能如FAQ问答失败则返回“暂未找到答案”能容忍局部失败如OCR失败则跳过图片分析用文本继续不能如信贷审批中征信查询失败必须阻塞并人工介入Q3是否有明确的SLA指标需监控如P95延迟≤3s错误率0.5%否无生产环境压力是但仅需基础指标总耗时、成功率是且需细粒度指标各工具调用耗时、重试次数、降级率Q4未来6个月是否计划接入≥3个新工具或数据源否当前能力已固化是但工具类型相似如都是HTTP API是且工具异构性强如既有RESTful API又有Kafka消息队列还有本地Python函数注意只要Q1或Q2任一题选“L3适用答案”就必须启动Runtime建设。我们曾有个客户在Q1选“是”Q2选“能容忍”结果上线后发现当OCR工具因网络抖动超时Agent会反复重试3次每次重试都触发新的支付预授权导致用户银行卡被冻结。根源就是Q2判断失误——表面看是“局部失败”实则引发跨系统副作用。所以Q2的答案必须基于实际业务影响而非技术假设。3. 核心细节解析与实操要点Runtime不是黑盒它的每个齿轮都必须亲手拧紧3.1 工具注册表Tool Registry别让“动态加载”变成线上事故几乎所有Runtime框架都提供register_tool()方法但90%的团队栽在同一个细节工具描述的完备性。我们见过太多案例因为少填了一个字段导致生产环境雪崩。以一个典型的财务API工具为例正确注册应包含以下7个必填项缺一不可# ✅ 生产级工具注册示例伪代码 register_tool( nameget_reimbursement_status, # 必须全局唯一禁止空格/特殊字符 description根据报销单ID查询当前审批状态及处理人, # 供LLM理解用途非注释 input_schema{ # 必须是JSON Schema Draft-07LLM据此生成参数 type: object, properties: { reimburse_id: {type: string, minLength: 6, maxLength: 12}, timeout_seconds: {type: integer, default: 5, minimum: 1} }, required: [reimburse_id] }, output_schema{ # 必须声明用于后续步骤的输入校验 type: object, properties: { status: {enum: [draft, reviewing, approved, rejected]}, approver_name: {type: string}, last_updated: {type: string, format: date-time} } }, auth_typeoauth2_client_credential, # 明确鉴权方式Runtime据此注入token timeout8.0, # 工具级超时必须≤全局超时 max_retries2, # 重试策略非LLM重试 is_idempotentTrue, # 关键决定是否允许重试GET类接口为TruePOST为False )实操心得is_idempotent是最高频误配项。某客户将支付接口设为True结果网络超时后Runtime自动重试造成用户被重复扣款。后来我们强制要求所有POST/PUT/PATCH方法的工具is_idempotent必须显式设为False并在注册时校验input_schema中是否含idempotency_key字段。这才是工程化的底线。3.2 执行计划Plan生成别迷信“自主规划”先锁死你的Plan Schema很多团队痴迷于让LLM“自己想出执行步骤”结果上线后发现模型生成的Plan格式千奇百怪今天返回[{tool:a,args:{}}]明天变成{steps:[{name:a,params:{}}]}导致解析器天天报错。真正的生产实践是Plan不是LLM自由发挥的产物而是你定义的、带版本号的协议。我们采用三级Plan Schema设计V1最小可用固定两段式结构{ plan_id: uuid4, steps: [ {tool: ocr_service, input: {image_url: https://...}}, {tool: nlp_classifier, input: {text: {{step_0.output.text}}}} ] }✅ 优点解析简单LLM容易遵循在system prompt中强制要求“严格按此JSON格式输出”❌ 缺点不支持条件分支、循环、并行V2生产推荐支持条件与并行{ plan_id: uuid4, steps: [ {id: s1, tool: ocr_service, input: {image_url: ...}}, {id: s2, tool: nlp_classifier, input: {text: {{s1.output.text}}}}, {id: s3, tool: send_notification, input: {content: OCR完成}, when: s1.status success}, {id: s4, tool: alert_human, input: {error: {{s1.error}}}, when: s1.status failed} ] }✅ 优点覆盖95%业务场景when表达式由Runtime预编译非LLM生成杜绝语法错误❌ 缺点需在prompt中约束LLM只生成steps数组不生成when逻辑由业务规则引擎动态注入V3高阶扩展支持子流程与状态机{ plan_id: uuid4, state_machine: { initial_state: wait_for_upload, states: { wait_for_upload: {on: {file_uploaded: parse_document}}, parse_document: {actions: [ocr_service, pdf_to_text], on_success: validate_data}, validate_data: {actions: [rule_engine], on_failure: alert_human} } } }✅ 优点与现有工作流引擎如Camunda无缝集成天然支持长时间运行任务如审批流❌ 缺点LLM仅负责初始状态触发后续完全由状态机驱动对LLM依赖度最低注意永远不要让LLM生成when条件或状态转移逻辑。我们实测过在1000次调用中LLM生成的when表达式有17%存在语法错误如写成或忘记引号。正确的做法是LLM只输出stepswhen规则由独立的规则引擎如Drools或配置中心管理Runtime在执行时动态注入。3.3 内存抽象Memory Abstraction别把Redis当万能胶水提到Agent记忆很多人第一反应是“上Redis”。但真实场景中你需要至少三种内存短期记忆Short-term Memory存储单次会话内的上下文如用户刚上传的发票图片、OCR识别出的文字。要求低延迟5ms、高吞吐。✅ 推荐进程内LRU Cache如functools.lru_cache或内存数据库如LiteDB。❌ 避免Redis网络IO开销过大单次读写10ms。长期记忆Long-term Memory存储用户画像、历史偏好、知识图谱。要求强一致性、支持复杂查询。✅ 推荐PostgreSQL用pgvector插件支持向量检索或专用向量数据库如Qdrant。❌ 避免纯Key-Value存储无法做语义检索。对话记忆Conversation Memory存储多轮对话的摘要、关键决策点、待办事项。要求可追溯、可编辑、支持时间线回溯。✅ 推荐专用对话数据库如ChatDB或结构化日志Elasticsearch 自定义mapping。❌ 避免把所有对话存Redis Hash无法按时间范围查询无法全文检索。我们为某教育客户设计的记忆架构如下短期记忆使用concurrent.futures.ThreadPoolExecutor管理的dictkey为session_idvalue为{last_ocr_result: ..., pending_tasks: [...]}。进程重启后自动清空符合业务预期。长期记忆PostgreSQL表user_profiles含embedding列768维float数组查询时用-操作符计算余弦相似度。对话记忆Elasticsearch索引conversation_tracesmapping中定义messages为nested类型支持messages.content: 报销 AND messages.timestamp 2024-01-01这类复合查询。实操心得短期记忆必须与执行线程绑定。某客户用Redis存储短期记忆结果在高并发下出现会话错乱——用户A的OCR结果被用户B的后续步骤读取。根源是Redis key设计为memory:{session_id}但代码中session_id生成逻辑有竞态条件。改为进程内内存后问题消失。4. 实操过程与核心环节实现从零搭建一个可运行的Harness Runtime4.1 基础骨架用不到200行代码定义Runtime核心契约我们不从框架开始而是先写一个最小可行RuntimeMVR它只做四件事接收Plan、调度工具、记录Trace、返回结果。所有代码均可直接运行Python 3.9# runtime/core.py import asyncio import json import time from dataclasses import dataclass, field from typing import Dict, Any, List, Optional, Callable, Awaitable dataclass class Tool: name: str description: str input_schema: dict output_schema: dict func: Callable[..., Awaitable[Any]] timeout: float 10.0 max_retries: int 1 is_idempotent: bool False dataclass class StepExecution: step_id: str tool_name: str input: Dict[str, Any] status: str pending # pending/running/success/failed output: Optional[Any] None error: Optional[str] None start_time: float field(default_factorytime.time) end_time: float 0.0 dataclass class Plan: plan_id: str steps: List[Dict[str, Any]] class HarnessRuntime: def __init__(self): self.tools: Dict[str, Tool] {} self.traces: Dict[str, List[StepExecution]] {} def register_tool(self, tool: Tool): 注册工具强制校验schema assert tool.name.isalnum(), fTool name must be alphanumeric: {tool.name} assert type in tool.input_schema, finput_schema missing type: {tool.name} self.tools[tool.name] tool async def execute_plan(self, plan: Plan) - Dict[str, Any]: 执行Plan返回结构化结果 trace_id ftrace_{int(time.time())}_{plan.plan_id[:6]} self.traces[trace_id] [] # 解析Plan生成可执行Step对象 steps [] for i, step_dict in enumerate(plan.steps): step StepExecution( step_idfstep_{i}, tool_namestep_dict[tool], inputstep_dict.get(input, {}) ) steps.append(step) # 串行执行简化版生产环境需支持并行/条件 for step in steps: try: tool self.tools[step.tool_name] # 注入trace_id到工具调用上下文供日志埋点 result await asyncio.wait_for( tool.func(**step.input, _trace_idtrace_id), timeouttool.timeout ) step.status success step.output result step.end_time time.time() except Exception as e: step.status failed step.error str(e) step.end_time time.time() # 非幂等工具失败不重试 if not tool.is_idempotent: break self.traces[trace_id] steps return { plan_id: plan.plan_id, trace_id: trace_id, status: success if all(s.status success for s in steps) else failed, steps: [s.__dict__ for s in steps], duration_ms: (steps[-1].end_time - steps[0].start_time) * 1000 } # 示例工具模拟OCR服务 async def mock_ocr_service(image_url: str, _trace_id: str) - Dict[str, str]: await asyncio.sleep(0.3) # 模拟网络延迟 return {text: fOCR_RESULT_FROM_{image_url.split(/)[-1].split(.)[0]}} # 使用示例 if __name__ __main__: rt HarnessRuntime() rt.register_tool(Tool( nameocr_service, descriptionExtract text from image URL, input_schema{type: object, properties: {image_url: {type: string}}}, output_schema{type: object, properties: {text: {type: string}}}, funcmock_ocr_service, timeout5.0, is_idempotentTrue )) # 构造Plan plan Plan( plan_idplan_abc123, steps[{tool: ocr_service, input: {image_url: https://example.com/invoice.jpg}}] ) # 执行 result asyncio.run(rt.execute_plan(plan)) print(json.dumps(result, indent2, ensure_asciiFalse))这段代码的价值不在于功能多强大而在于它显式暴露了Runtime的核心契约Plan是什么结构Tool必须提供哪些元信息Execution状态如何流转Trace如何关联当你把这200行代码跑通你就拥有了一个可调试、可测试、可替换任意模块的坚实基座。4.2 工具调用增强给每个工具装上“保险丝”和“黑匣子”生产环境的工具调用绝不能裸奔。我们在基础Runtime上叠加三层防护第一层超时熔断Circuit Breaker使用aiocircuit库为每个工具配置独立熔断器from aiocircuit import CircuitBreaker # 为高频工具配置激进熔断 ocr_breaker CircuitBreaker( failure_threshold3, # 连续3次失败开启熔断 recovery_timeout60, # 60秒后尝试半开 expected_exception(TimeoutError, ConnectionError) ) ocr_breaker async def robust_ocr_service(image_url: str, _trace_id: str): return await mock_ocr_service(image_url, _trace_id)第二层输入/输出校验Schema Validation使用jsonschema在调用前后校验import jsonschema from jsonschema import validate def validate_tool_io(tool: Tool, input_data: dict, output_data: dict): try: validate(instanceinput_data, schematool.input_schema) except jsonschema.ValidationError as e: raise ValueError(fInput validation failed for {tool.name}: {e}) try: validate(instanceoutput_data, schematool.output_schema) except jsonschema.ValidationError as e: raise ValueError(fOutput validation failed for {tool.name}: {e})第三层可观测性埋点OpenTelemetry在execute_plan中注入tracefrom opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor # 初始化Tracer provider TracerProvider() processor SimpleSpanProcessor(ConsoleSpanExporter()) provider.add_span_processor(processor) trace.set_tracer_provider(provider) tracer trace.get_tracer(__name__) # 在execute_plan中 with tracer.start_as_current_span(plan_execution, attributes{plan_id: plan.plan_id}): # ... 执行步骤 ... for step in steps: with tracer.start_as_current_span(fstep_{step.step_id}, attributes{ tool: step.tool_name, input_hash: hash(json.dumps(step.input, sort_keysTrue)) }): # ... 调用工具 ...实操心得熔断器必须按工具粒度配置。某客户给所有工具共用一个熔断器结果OCR服务抖动导致支付接口也被熔断。后来改为每个工具独立熔断器并设置不同阈值OCRfailure_threshold5支付failure_threshold1。4.3 可观测性落地用10行代码构建可定位的Trace体系没有Trace的Agent就像没有仪表盘的飞机。我们坚持一个原则所有关键节点必须生成可关联的trace_id。以下是生产环境必备的5类TraceTrace类型生成位置关联方式用途plan_traceexecute_plan()入口trace_id作为函数参数传入定位整个任务生命周期step_trace每个StepExecution开始parent_id plan_trace.id定位单步耗时与失败原因tool_trace工具调用前parent_id step_trace.id定位网络延迟、认证失败llm_traceLLM API调用前parent_id step_trace.id定位prompt质量、模型响应慢memory_trace内存读写时parent_id step_trace.id定位上下文污染、缓存失效实现上我们用一个轻量级TraceContext类统一管理# runtime/trace.py import uuid from contextvars import ContextVar _trace_context_var ContextVar(trace_context, defaultNone) class TraceContext: def __init__(self, parent_id: str None): self.trace_id str(uuid.uuid4()) self.parent_id parent_id self.spans [] def new_span(self, name: str, attributes: dict None) - Span: span Span(self.trace_id, self.parent_id, name, attributes) self.spans.append(span) return span def to_dict(self) - dict: return { trace_id: self.trace_id, parent_id: self.parent_id, spans: [s.to_dict() for s in self.spans] } class Span: def __init__(self, trace_id: str, parent_id: str, name: str, attributes: dict None): self.trace_id trace_id self.parent_id parent_id self.name name self.attributes attributes or {} self.start_time time.time() self.end_time None def end(self): self.end_time time.time() def to_dict(self) - dict: return { name: self.name, attributes: self.attributes, start_time: self.start_time, duration_ms: (self.end_time - self.start_time) * 1000 if self.end_time else 0 } # 在execute_plan中 def execute_plan(self, plan: Plan): ctx TraceContext() # ... 执行逻辑 ... for step in steps: span ctx.new_span(fstep_{step.step_id}, {tool: step.tool_name}) # ... 执行工具 ... span.end() # 输出完整trace print(json.dumps(ctx.to_dict(), indent2))这套Trace体系让我们在某次线上事故中3分钟定位根因plan_trace显示总耗时12sstep_trace发现step_2耗时11.8stool_trace显示payment_gateway调用耗时11.7sllm_trace正常200ms。结论支付网关异常非Agent问题。运维直接切流量避免了无谓的代码回滚。5. 常见问题与排查技巧实录那些文档里不会写的血泪教训5.1 “LLM总是生成不存在的工具名”——不是模型问题是Prompt工程缺陷现象Agent频繁调用get_user_profile_v2实际注册的是get_user_profile或虚构send_sms_alert实际只有send_email_alert。根因分析LLM在训练时见过大量API文档会“脑补”合理名称description字段写得太笼统如“获取用户信息”未强调“必须严格匹配注册名”。解决方案Prompt中强制约束在system prompt末尾添加IMPORTANT: You MUST use ONLY the following tool names exactly as listed below. Do NOT invent new tool names or add suffixes like _v2. If no tool matches, output {error: no_tool_found}. Available tools: get_user_profile, send_email_alert, update_ticket_status注册时增加别名映射register_tool( nameget_user_profile, aliases[get_user_profile_v1, fetch_user_data], # LLM可任选其一 # ... )执行前做模糊匹配from difflib import get_close_matches def resolve_tool_name(tool_name: str) - str: candidates list(runtime.tools.keys()) matches get_close_matches(tool_name, candidates, n1, cutoff0.6) return matches[0] if matches else None实操心得别信“LLM会自动纠错”。我们测试过当cutoff0.6时92%的拼写错误能被纠正但若设为0.8纠错率暴跌至35%且误纠率升至18%。0.6是精度与召回的黄金平衡点。5.2 “工具调用成功但结果为空”——90%是JSON Schema校验惹的祸现象工具函数返回{status: success, data: null}但Runtime报Output validation failed。根因分析output_schema中data字段定义为{type: string}但实际返回null或data是可选字段但schema未声明nullable: true。解决方案Schema必须声明nullable{ type: object, properties: { data: { anyOf: [ {type: string}, {type: null} ] } } }工具函数做防御性包装async def safe_tool_wrapper(func, *args, **kwargs): try: result await func(*args, **kwargs) # 强制转换为schema兼容格式 if result is None: return {data: None} return result except Exception as e: return {error: str(e), data: None}5.3 “高并发下内存暴涨”——不是泄漏是短期记忆没清理现象Runtime进程RSS内存持续增长重启后回落但几小时内又涨满。根因分析短期记忆如dict未设置TTL旧会话数据永久驻留lru_cache未设maxsize缓存无限增长。解决方案为短期记忆加TTLfrom cachetools import TTLCache short_term_memory TTLCache(maxsize1000, ttl300) # 5分钟过期监控内存使用import psutil def log_memory_usage(): process psutil.Process() mem_info process.memory_info() print(fRSS: {mem_info.rss / 1024 / 1024:.1f} MB) # 每10秒打印一次 asyncio.create_task(log_memory_usage_loop())设置OOM Killer阈值在Docker启动时添加--memory2g --memory-swap2g --oom-kill-disablefalse让系统在内存超限时主动杀掉进程而非让整个容器僵死。注意绝对不要用gc.collect()试图解决内存问题。我们曾有个客户在每次Plan执行后调用gc.collect()结果GC线程CPU占用飙升至90%反而拖垮了整个服务。内存问题必须从设计源头解决而非事后补救。5.4 “Trace日志查不到”——分布式环境下Context丢失现象本地测试Trace完美但部署到K8s后step_trace的parent_id为空。根因分析
阅读完成 · 觉得有帮助？
