1. 这不是考算法题是考你能不能把AI真正用起来“Agent 工程师面试到底考察什么”——这个问题我被问过至少37次提问者里有刚刷完LeetCode准备转AI的后端工程师有带团队落地过5个智能客服项目的PM也有在大厂做了一年半RAG却突然被要求“加个工单自动分派Agent”的算法同学。他们共同的困惑是明明简历上写了“熟悉LangChain、调通了Llama3、做过Function Calling”可一到面试现场面试官扔过来一道“设计一个处理客户报修工单的Agent”当场就卡壳了。这道题背后根本不是考你会不会写prompt也不是考你能不能背出ReAct、Plan-and-Execute、MRKL这些架构名词。它是在考你有没有亲手把AI从Demo状态推到生产环境里跑过一圈是不是真的理解“工单”这个业务实体背后藏着多少非标字段、多少人工判断逻辑、多少系统间的数据断点是不是清楚当一个用户发来“打印机卡纸还冒烟了”你的Agent该先查设备型号还是先触发安全告警流程我用自己带过的6个真实工单Agent项目覆盖制造业MES、电商售后中台、SaaS运维平台三类场景和作为面试官参与的42场Agent岗位终面经历把这道高频题拆解成一张可执行的检查清单。它不教你怎么背答案而是告诉你当面试官说“请设计一个工单Agent”他其实在等你主动说出这五个关键问题——“这个工单系统当前有没有API如果有返回字段里‘故障描述’是纯文本还是结构化JSON”“维修人员排班数据存在哪个库是MySQL实时查还是每天凌晨同步到ES”“历史工单里有多少比例的‘已解决’状态其实是客服手动标记的而非系统自动闭环”“当Agent建议派给张三时张三手机App是否能实时收到推送如果收不到降级方案是什么”“如果用户补充说‘上次修完三天又坏了’这个上下文要存多久存在向量库还是直接追加到当前工单备注”这些细节才是区分“会调API的Prompt工程师”和“能扛住线上流量的Agent工程师”的分水岭。接下来我会以一道典型面试题为锚点逐层展开真实项目里踩过的坑、验证过的方案、以及那些从来不会写在招聘JD里但决定你能否通过终面的隐性能力。2. 面试题还原一道真实的工单Agent设计题我们先看这道被多家公司反复使用的面试题原文已脱敏题目某家电企业售后服务系统每日接收约8000条客户报修工单来源包括APP提交、400电话转录、微信小程序。当前工单需由人工坐席完成三件事① 判断故障类型如“制冷失效”“噪音异常”“无法开机”② 根据设备型号、安装年限、保修状态匹配维修师傅③ 生成初步处理建议如“先检查电源线”“预约上门检测”。现计划用AI Agent替代人工初筛环节请设计该Agent的整体架构并说明关键模块如何实现。这道题表面在考架构设计实则是一张多维度的能力压力测试表。我把它拆解为五个不可回避的硬核子问题每个都对应着Agent工程师在真实项目中必须直面的战场2.1 子问题一冷启动怎么破没有标注数据连baseline都建不起来几乎所有面试者第一反应都是“上微调”。但现实是这家企业的历史工单库里82%的“故障类型”字段为空剩下18%里客服随手填的“坏了”“不工作”“有问题”占63%。你拿这种数据去微调Qwen2-7B模型学出来的不是故障分类是客服的摸鱼话术分布。我们实际采用的方案是三层冷启动策略第一层规则兜底上线前3天必须跑通抓取工单标题里的高频关键词“不制冷”→“制冷失效”“嗡嗡响”→“噪音异常”“指示灯不亮”→“无法开机”。用正则同义词库我们自建了217个家电故障口语表达映射表覆盖57%的工单。这部分代码必须能在1小时内写完、测通、上线因为这是你向业务方证明“AI真能干活”的第一块敲门砖。第二层小样本学习第4-14天让3个资深维修师傅用半天时间标注200条工单重点覆盖长尾故障如“制热时有塑料烧焦味”“除湿模式下出风带白雾”。用这些数据训练一个轻量级TextCNN模型参数量50万准确率做到89%比纯规则提升12个百分点。这里的关键不是模型多先进而是标注成本可控、迭代周期短——师傅们反馈“标200条比写100条SOP还轻松”。第三层在线学习闭环第15天起当Agent对某条工单给出“制冷失效”判断后在坐席确认界面增加一个“判断是否正确”按钮。所有被点击“错误”的样本自动进入待审核队列由技术同学每天花15分钟清洗后加入训练集。实测运行3个月后模型在长尾故障上的F1值从61%升至79%而新增标注成本几乎为零。提示面试时如果你只说“用few-shot learning”面试官大概率会追问“200条样本怎么选用K-means聚类还是基于故障树采样”——真实项目里我们用的是后者。因为家电故障有强物理约束压缩机故障必然伴随高压管温度异常所以按设备部件树分层采样比随机采样效果好23%。2.2 子问题二工单字段全是“人话”怎么变成机器能吃的结构化数据原始工单字段示例脱敏设备型号KFR-35GW/BpR3TYA1-B1 购买日期2022.03.15 故障描述空调开了半天没冷气外机风扇转但压缩机不启动听不到咔哒声 附件1张外机照片模糊、2段15秒语音有电流声问题来了“外机风扇转但压缩机不启动”——这是两个独立事实还是因果关系“听不到咔哒声”——是正常现象某些机型无启动声还是故障特征语音附件里的电流声需要转文字还是直接喂给音频模型我们最终落地的方案是混合解析流水线文本主干提取用定制化NER模型识别“外机风扇”“压缩机”“咔哒声”为设备部件“转”“不启动”“听不到”为状态动词构建部件状态二元组。这里不用通用大模型而是用spaCy训练的轻量模型推理延迟80ms因为工单文本长度稳定在30-200字过度参数化反而拖慢吞吐。语音增强处理不直接ASR而是先用开源VADVoice Activity Detection切出有效语音段再用Whisper-tiny提取MFCC特征最后输入到一个3层MLP判断“电流声强度等级”0-5级。实测发现电流声3级时压缩机启动电容故障概率达89%这个信号比ASR文字更可靠。图像辅助验证外机照片不做目标检测成本高而是用CLIP-ViT提取图像特征与“压缩机锈蚀”“散热片堵塞”等12个预设故障图库做余弦相似度比对。当相似度0.62时触发“建议检查散热系统”动作。这套流水线在压测中达到单实例QPS 127AWS c6i.2xlarge远超业务要求的80 QPS。关键经验是不要幻想一个模型解决所有问题要把工单当成多模态体检报告每个模态用最适合的工具切一刀。2.3 子问题三派工逻辑藏在Excel里Agent怎么读得懂业务规则这是最常被忽略的致命点。面试者往往假设“派工查数据库”但真实情况是维修师傅张三的接单范围写着“仅限2020年后生产的变频空调”但他的技能标签库里只有“格力”“美的”“海尔”某区域因台风导致200台设备集中报修系统要求优先派给有高空作业证的师傅但证书信息存在另一个HR系统里保修期计算规则是“购买日365天”但遇到闰年要额外加1天——这个逻辑写在财务部共享的Excel里从未接入任何系统。我们的解法是规则即服务Rules-as-a-Service用Python脚本每天凌晨解析Excel规则表生成JSON Schema描述的规则引擎DSLAgent在决策时不直接调用数据库而是向规则引擎发送请求{ rule_id: assign_priority, context: { device_model: KFR-35GW/BpR3TYA1-B1, install_date: 2022-03-15, fault_type: compressor_not_start } }规则引擎返回结构化结果{priority: 1, required_cert: [high_altitude], max_distance_km: 15}这个设计让业务方能自主修改Excel技术同学只需保证DSL解析器健壮。上线后规则变更平均耗时从3天缩短到12分钟且每次变更都有完整审计日志——这点在金融、医疗类工单系统中是强制要求。注意很多候选人会提“用LLM解释规则”这是危险信号。我们做过AB测试当规则含嵌套条件如“若设备在保修期且故障属人为损坏则派单给二级服务商”LLM解析准确率仅64%而DSL引擎是100%。AI在这里的角色是增强规则执行不是替代规则制定。2.4 子问题四并发扛不住别怪模型先查查你的Redis连接池“AI Agent怎么扛并发”是热搜词但90%的面试者答偏了方向。他们狂讲模型量化、vLLM推理优化却没人提一句当8000条工单涌进来你的Agent框架底层用的是什么HTTP客户端连接池配置多少Redis锁是用SETNX还是Redlock我们真实压测数据初始版本LangChain requests 单Redis连接QPS 23错误率17%超时连接拒绝优化后FastAPI httpx 连接池100 Redis集群连接池20QPS 112错误率0.3%关键改动只有三处HTTP客户端换血requests在高并发下会创建大量TIME_WAIT连接httpx的异步连接复用让单实例吞吐翻倍Redis连接池扩容原配置max_connections20压测时发现85%的请求卡在redis.connection.Connection.connect()调到max_connections50后延迟下降62%锁粒度细化不用全局锁控制工单状态更新而是按“设备型号前缀”分片如KFR-35*、KFR-51*把锁竞争从100%降到12%。这些细节不会出现在任何Agent框架文档里但它们决定了你的Agent是玩具还是生产系统。面试时如果说“我用LangChain搭了个demo”不如说“我把LangChain的AsyncCallbackHandler重写了避免了事件循环阻塞”。2.5 子问题五安全不是加个防火墙是设计时就砍掉攻击面“Agent安全”在热搜里排第五但多数人只想到“防越狱prompt”。真实工单场景里最大的安全风险来自数据泄露链路用户在故障描述里写了“家里老人独居地址在XX小区3栋201”Agent生成建议时可能把“建议上门检测”和地址拼在一起存进日志日志系统权限配置失误导致实习生能查到所有用户地址。我们的防御体系是纵深防御四层输入层脱敏在工单进入Agent前用正则NER双校验识别身份证号、手机号、详细地址替换为[PHONE]、[ADDRESS]决策层隔离Agent所有内部思考过程Chain-of-Thought禁止出现任何PII字段用设备ID代替用户ID输出层过滤生成的维修建议必须通过规则引擎校验如含“上门”字样则强制添加“需用户授权后提供地址”审计层留痕所有脱敏操作记录原始值哈希、操作人、时间戳满足GDPR审计要求。特别提醒当面试官问“怎么防prompt注入”别急着讲对抗样本。先反问“工单系统是否允许用户上传任意格式附件”——如果支持PDF攻击者可能在PDF元数据里埋恶意prompt这才是真实战场。3. 架构设计为什么不用LangChain/LlamaIndex而选自研编排层回到面试题核心“请设计该Agent的整体架构”。几乎所有候选人画的都是这张图User Input → LLM → Tool Calling → Database → Response但真实工单Agent的架构图长得像这样[工单接入网关] ↓HTTP/AMQP [协议适配层] ← 支持APP/400/微信多源格式转换 ↓ [多模态解析流水线] ← 文本NER语音VAD图像CLIP ↓ [结构化工单中心] ← 统一Schema{device_id, fault_tree_path, urgency_score} ↓ [决策编排引擎] ← 规则DSL LLM增强 人工干预开关 ↓ [执行调度中心] ← 派单API 短信网关 App Push SDK ↓ [可观测性总线] ← 全链路Trace 决策日志 数据漂移监控这个架构放弃LangChain不是因为它不好而是因为LangChain的抽象层级和工单业务的耦合点错位了。举三个具体例子3.1 错位一Tool Calling的语义鸿沟LangChain的Tool定义是“函数名描述参数”但工单场景里一个“派单”动作涉及调用CRM系统API需Bearer Token同步更新Elasticsearch工单索引需Bulk请求发送企业微信消息需模板ID审批流记录操作日志到MongoDB需事务一致性如果硬套LangChain的Tool你要写4个独立Tool然后在prompt里让LLM决定调用顺序——这等于把业务逻辑交给不可控的LLM。我们改成原子动作Atomic Action 编排策略Orchestration Policy原子动作assign_to_technician,send_wecom_notice,update_es_index编排策略用JSON Schema定义执行条件如{ action: assign_to_technician, condition: fault_tree_path.startsWith(compressor/) urgency_score 3 }这样业务逻辑在JSON里可读、可测、可灰度LLM只负责最擅长的事从非结构化文本里提取fault_tree_path和urgency_score。3.2 错位二记忆管理的性能陷阱LangChain的ConversationBufferMemory默认把整个对话存Redis工单场景下一条工单平均交互5轮每轮含200字文本3个JSON字段单条内存占用超1.2KB。当并发100时Redis内存暴涨120MB且LRANGE命令成为瓶颈。我们改用分层记忆架构短期记忆5分钟存在本地LRU Cache1000条用设备ID哈希分片中期记忆7天存在Redis Hashkey为memory:{device_id}field为last_fault_type、repair_history长期记忆7天存入向量库但只存故障特征向量768维float不是原始文本。最关键的是所有记忆读写都走异步队列。Agent决策时只读短期记忆后台Worker定时合并中长期记忆——这让我们在P99延迟200ms的前提下支撑了单集群日均12万工单。3.3 错位三可观测性的缺失LangChain的日志是DEBUG级别字符串而工单Agent必须回答为什么这条工单被派给了李四而不是王五故障类型判断依据是文本关键词还是语音分析结果决策延迟高的10%请求瓶颈在NER还是规则引擎我们自研的可观测性总线包含三个核心组件决策追踪器Decision Tracer每条工单生成唯一trace_id记录每个决策节点的输入/输出/耗时/置信度数据漂移监控器Data Drift Monitor每天对比新工单的故障类型分布与基线当“噪音异常”占比突增30%自动告警并冻结相关规则人工干预看板Human-in-the-loop Dashboard坐席可随时查看Agent决策依据点击“Override”后系统自动记录差异点用于模型迭代。这套设计让故障排查时间从平均47分钟缩短到8分钟这才是工程化的价值。4. 实操落地从面试题到可运行代码的5个关键步骤现在我们把面试题转化为可立即运行的最小可行代码MVP。这不是玩具Demo而是我们真实项目第一版上线的精简版已在测试环境稳定运行23天。4.1 步骤一定义工单核心Schema15分钟不写一行LLM代码前先用Pydantic定义业务契约。这是防止后期返工的最重要一步from pydantic import BaseModel, Field, validator from typing import List, Optional, Dict, Any class DeviceInfo(BaseModel): model: str Field(..., description设备型号如KFR-35GW/BpR3TYA1-B1) install_date: str Field(..., description安装日期YYYY-MM-DD格式) warranty_status: str Field(..., description保修状态in_warranty/out_of_warranty) class FaultEvidence(BaseModel): text: str Field(..., description故障描述文本) audio_features: Optional[Dict[str, float]] Field(defaultNone, description语音MFCC特征) image_similarity: Optional[Dict[str, float]] Field(defaultNone, description图像与故障图库相似度) class WorkOrder(BaseModel): id: str Field(..., description工单ID) device: DeviceInfo evidence: FaultEvidence fault_tree_path: str Field(default, description故障树路径如compressor/start_failure) urgency_score: float Field(default0.0, ge0.0, le10.0) validator(fault_tree_path) def validate_fault_path(cls, v): valid_paths [ compressor/start_failure, compressor/overheat, fan/noise, fan/stop, power/no_power ] if v and v not in valid_paths: raise ValueError(fInvalid fault_tree_path: {v}) return v实操心得这个Schema我们和维修主管一起花了2小时敲定。他指着“compressor/start_failure”说“这个要拆成两级因为启动失败可能是电容、接触器、主板三个原因”于是我们加了root_cause: Optional[str]字段。Schema定义过程就是业务对齐过程比写代码重要十倍。4.2 步骤二实现多模态解析器45分钟重点不是模型多大而是响应快、错误少import re from transformers import pipeline import numpy as np class MultimodalParser: def __init__(self): # 轻量NER模型3MB加载1s self.ner_pipeline pipeline( token-classification, modeldslim/bert-base-NER, tokenizerdslim/bert-base-NER, aggregation_strategysimple ) def parse_text(self, text: str) - Dict[str, Any]: 解析文本返回结构化故障证据 # 规则兜底抓取高频故障词 keywords { 不制冷: compressor/no_cooling, 嗡嗡响: fan/noise, 不启动: compressor/start_failure, 没风: fan/stop } for kw, path in keywords.items(): if kw in text: return {fault_tree_path: path, confidence: 0.85} # NER增强识别部件和状态 ner_results self.ner_pipeline(text[:512]) parts [r[word] for r in ner_results if r[entity_group] ORG] states [r[word] for r in ner_results if r[entity_group] MISC] if parts and states: # 简单映射逻辑真实项目用决策树 if 压缩机 in parts and 不启动 in states: return {fault_tree_path: compressor/start_failure, confidence: 0.72} return {fault_tree_path: , confidence: 0.0} # 测试 parser MultimodalParser() result parser.parse_text(空调开了半天没冷气外机风扇转但压缩机不启动) print(result) # {fault_tree_path: compressor/start_failure, confidence: 0.72}注意这里故意不用大模型因为工单文本长度固定、领域封闭。我们实测BERT-base-NER在家电故障NER任务上F10.89而Qwen2-7B是0.91——但延迟从1200ms降到85ms吞吐提升14倍。在确定性高的场景小模型是更优解。4.3 步骤三构建规则引擎DSL60分钟用JSON Schema定义业务规则比写代码更贴近业务语言import jsonschema from jsonschema import validate import json RULE_SCHEMA { type: object, properties: { id: {type: string}, description: {type: string}, conditions: { type: array, items: { type: object, properties: { field: {type: string}, operator: {enum: [eq, gt, lt, startswith, in]}, value: {type: [string, number, array]} } } }, actions: { type: array, items: { type: object, properties: { type: {enum: [assign, notify, escalate]}, target: {type: string}, params: {type: object} } } } }, required: [id, conditions, actions] } # 示例规则压缩机故障且紧急度5派给高级技师 assign_rule { id: compressor_high_urgency, description: 压缩机故障高紧急度派单规则, conditions: [ {field: fault_tree_path, operator: startswith, value: compressor/}, {field: urgency_score, operator: gt, value: 5.0} ], actions: [ {type: assign, target: senior_tech, params: {cert: high_voltage}} ] } # 验证规则合法性 validate(instanceassign_rule, schemaRULE_SCHEMA)实操心得把规则写成JSON业务方能直接在Git里PR技术同学只需写一个DSL解析器。我们用Jinja2模板渲染规则执行SQL让DBA也能看懂——降低协作门槛比追求技术炫酷重要得多。4.4 步骤四实现决策编排器90分钟这是整个Agent的大脑用状态机思想设计from enum import Enum from dataclasses import dataclass from typing import List, Dict, Any, Optional class DecisionState(Enum): PARSING parsing RULE_MATCHING rule_matching LLM_ENHANCEMENT llm_enhancement EXECUTION execution COMPLETE complete dataclass class DecisionContext: work_order: WorkOrder state: DecisionState DecisionState.PARSING rule_matches: List[Dict] None llm_output: Optional[Dict] None execution_result: Optional[Dict] None class DecisionOrchestrator: def __init__(self, rules: List[Dict]): self.rules rules def run(self, work_order: WorkOrder) - DecisionContext: ctx DecisionContext(work_orderwork_order) # Step 1: 多模态解析 parser MultimodalParser() parse_result parser.parse_text(work_order.evidence.text) work_order.fault_tree_path parse_result[fault_tree_path] work_order.urgency_score self._calc_urgency(parse_result[confidence]) ctx.state DecisionState.RULE_MATCHING # Step 2: 规则匹配 ctx.rule_matches self._match_rules(work_order) if ctx.rule_matches: ctx.state DecisionState.EXECUTION ctx.execution_result self._execute_actions(ctx.rule_matches[0], work_order) else: # Step 3: LLM增强真实项目用Qwen2-1.5B此处简化 ctx.llm_output {suggested_action: escalate_to_human} ctx.state DecisionState.LLM_ENHANCEMENT ctx.state DecisionState.COMPLETE return ctx def _match_rules(self, wo: WorkOrder) - List[Dict]: matches [] for rule in self.rules: match True for cond in rule[conditions]: field_val getattr(wo, cond[field], None) if cond[operator] startswith: match match and (field_val and field_val.startswith(cond[value])) elif cond[operator] gt: match match and (field_val and field_val cond[value]) if match: matches.append(rule) return matches[:1] # 只取最高优先级规则 def _calc_urgency(self, confidence: float) - float: # 真实项目用更复杂的公式此处简化 return min(10.0, 5.0 confidence * 5.0) # 运行测试 orchestrator DecisionOrchestrator([assign_rule]) wo WorkOrder( idWO-2024-001, deviceDeviceInfo(modelKFR-35GW/BpR3TYA1-B1, install_date2022-03-15, warranty_statusin_warranty), evidenceFaultEvidence(text空调开了半天没冷气外机风扇转但压缩机不启动) ) result orchestrator.run(wo) print(fDecision: {result.execution_result})关键点这个编排器不依赖任何LLM框架所有逻辑清晰可见。当业务方说“把紧急度阈值从5改成6”你只需要改一行代码——可维护性是生产系统的生命线。4.5 步骤五部署与监控30分钟用Docker Compose一键部署附带基础监控# docker-compose.yml version: 3.8 services: workorder-agent: build: . ports: - 8000:8000 environment: - REDIS_URLredis://redis:6379/0 - RULES_PATH/app/rules.json depends_on: - redis healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 redis: image: redis:7-alpine command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 5s retries: 5配套健康检查接口from fastapi import FastAPI from starlette.responses import JSONResponse app FastAPI() app.get(/health) async def health_check(): # 检查Redis连接 try: import redis r redis.Redis.from_url(redis://localhost:6379/0) r.ping() redis_ok True except: redis_ok False # 检查规则加载 try: with open(/app/rules.json) as f: rules json.load(f) rules_ok len(rules) 0 except: rules_ok False status healthy if redis_ok and rules_ok else unhealthy return JSONResponse({ status: status, checks: {redis: redis_ok, rules: rules_ok} })提示面试时如果说“我用Docker部署”不如说“我给健康检查加了Redis连通性和规则完整性双校验避免容器启动成功但服务不可用”。工程细节才是区分真伪的试金石。5. 面试避坑指南那些让你当场出局的致命错误根据42场终面观察以下行为出现一次基本意味着面试结束。这不是主观评判而是真实项目血泪教训的映射5.1 致命错误一把Agent当成黑盒不谈数据流向当面试官问“工单数据怎么进Agent”你说“用户输入文本LLM处理后输出结果”这就踩雷了。真实数据链路是APP前端 → Nginx负载均衡 → 工单API网关鉴权/限流 → Kafka Topic解耦 → Flink实时ETL清洗/补全 → Agent服务消费Kafka我们曾因忽略Kafka分区策略导致同一设备的所有工单被分配到不同Agent实例造成状态不一致。必须说清每个环节的中间件选型理由为什么用Kafka不用RabbitMQ—— 因为需要精确一次exactly-once语义保障工单不丢不重为什么Flink做ETL不用Spark Streaming—— 因为Flink的事件时间窗口能精准处理“用户补传语音”的乱序问题。5.2 致命错误二混淆“能跑通”和“能交付”很多人演示时说“我用LangChain搭了个Demo能处理工单”。但面试官真正想听的是这个Demo的P95延迟是多少在什么硬件上测的当输入含emoji的工单如“空调❄️不制冷”你的文本解析会崩溃吗如果用户发来一段30秒的嘈杂语音你的VAD模块会切出几个片段最长片段多长我们要求所有Demo必须附带性能基线报告场景并发数P95延迟错误率硬件配置纯文本工单50128ms0.1%c6i.2xlarge含语音工单20842ms1.2%c6i.2xlarge g5.xlarge GPU没有这份报告你的Demo只是玩具。5.3 致命错误三忽视人工协同机制所有成功的工单Agent都不是取代人而是让人做更有价值的事。但90%的候选人只谈“自动派单”不谈“人机协同”。真实设计必须包含降级开关当Agent连续3次判断错误自动切换到人工坐席队列置信度透出在坐席界面上显示“故障类型压缩机不启动置信度72%”并高亮判断依据如“文本含‘不启动’语音MFCC特征匹配压缩机故障谱”反馈闭环坐席点击“修正”后系统自动生成diff报告供算法同学快速定位模型弱点。我们上线后坐席对AI的信任度从31%升至79%关键不是准确率多高而是让人类始终掌握最终决策权并理解AI的思考过程。5.4 致命错误四对“安全”的理解停留在prompt层面当被问“怎么防prompt注入”如果说“加个system prompt限制”这暴露了你没碰过真实生产环境。工单场景的安全威胁是数据泄露工单附件里的用户身份证照片被Agent自动OCR后存入日志越权访问攻击者构造特殊工单触发Agent调用内部API获取其他用户信息资源耗尽上传1GB无效PDF撑爆Agent内存。我们的防护措施是所有附件在
