1. 什么是 AI Agent它不是“更聪明的聊天机器人”而是能自主完成任务的数字工人你有没有试过让一个大模型帮你订机票它能告诉你航班信息、价格区间甚至分析哪家航司准点率高——但真要它打开航司官网、填身份证号、选座位、输入支付密码完成下单它做不到。这不是模型能力不够而是它缺少“手脚”和“决策神经”。AI Agent 就是给大模型装上这双手脚、配上这套神经系统的工程产物。它不是把 LLM 当成问答机用而是把它当作一个“认知中枢”围绕这个中枢构建感知输入、规划思考、行动调用工具、反馈观察结果、修正迭代策略的完整闭环。标题里说的“七要素”和“七个决策点”本质上是在回答同一个问题当你要把一个静态的大语言模型变成一个能在真实世界里跑起来、干实事、出结果的数字工人时你必须在哪些关键位置做设计、做取舍、做工程实现这七个点每一个都对应着一个现实世界的约束LLM 的 token 限制决定了它不能记住所有历史工具调用的失败率要求你必须设计重试与降级用户意图的模糊性迫使你必须做多轮澄清系统响应的延迟又倒逼你优化执行路径。所以搞懂 Agent绝不是背几个概念名词而是理解这七个点如何像齿轮一样咬合在一起共同对抗真实业务场景里的混乱、不确定和资源限制。这篇文章不讲抽象理论只讲我在三个生产级 Agent 项目里踩过的坑、验证过的方案、以及为什么某个参数必须设成 3 而不是 5——因为设成 5下游数据库连接池就直接被打满整个服务雪崩。它适合两类人一类是刚学完 LangChain 想动手搭个 demo 的开发者另一类是技术负责人正被老板追问“Agent 到底能不能扛住每天百万级订单的自动审核”。如果你属于前者看完你会知道第一步该删掉哪三行代码如果你属于后者你会明白为什么“并发”不是加机器就能解决的问题而是七个决策点中任何一个没对齐都会成为并发瓶颈的单点。2. 七要素Agent 的骨架缺一不可但每个都藏着工程陷阱AI Agent 的七要素不是教科书上的漂亮分类而是从无数线上故障日志里反推出来的最小必要组件集合。它们像一栋楼的地基、承重墙、水电管线、消防通道、电梯井、门窗和屋顶——少一个楼可能盖得起来但住进去的人随时会遇到漏水、断电、被困或者失火。我见过太多团队一开始只关注“LLM 工具调用”这两个最显眼的要素结果上线后发现用户问“查一下我上个月的账单”Agent 却反复调用天气 API或者连续三次调用支付接口失败后它既不报错也不降级就卡在那里不动了。问题不在模型而在骨架没搭牢。下面我逐个拆解这七个要素重点讲清楚每个要素在工程落地时为什么必须存在以及最容易被忽略的实操细节。2.1 输入解析层不是简单接收文本而是启动一场精准的意图捕获战很多团队把用户输入直接丢给 LLM认为“模型自己会理解”。这是最大的误区。LLM 是强大的通用推理器但不是万能的意图翻译官。它需要清晰、结构化的指令才能稳定输出。输入解析层的核心任务是把一句口语化的“帮我看看昨天那笔转账到账没”转换成 Agent 内部可执行的结构化指令{“action”: “query_transaction”, “params”: {“date”: “2024-05-15”, “amount”: null, “receiver”: null}}。这个过程远不止分词或关键词提取。它包含三个关键子环节第一是上下文锚定。用户说“那笔转账”这个“那笔”指什么是上一条消息还是最近一次成功的支付还是用户当前会话中提到的某一笔我们在线上系统里用了双锚点机制主锚点是会话 ID 关联的 Redis Hash存最近 5 条用户主动发起的交易类指令辅锚点是 LLM 输出的 JSON 中强制要求的reference_id字段用于跨轮次精确回溯。如果两个锚点冲突系统优先信任辅锚点但会记录告警日志——因为这往往意味着 LLM 在“编造”参考依据。第二是歧义消解。用户说“查账单”是指“电子账单 PDF”、“交易明细列表”还是“余额变动通知”我们不依赖 LLM 猜而是在解析层内置一个轻量级规则引擎。它基于用户历史行为比如过去 7 天内 80% 的“查账单”请求都指向 PDF 下载、当前设备类型移动端更倾向明细列表、以及请求中的隐含线索带“下载”字眼的99% 指 PDF给出一个概率最高的意图标签并附带置信度。只有置信度 0.85才进入下一步否则触发澄清流程“您想查看的是账单明细还是下载 PDF 版本”第三是安全过滤前置。所有输入在进入 LLM 之前必须经过一层硬规则过滤。这不是为了防“敏感词”而是防逻辑炸弹。比如用户输入“请重复执行上一条指令 1000 次”或者“把数据库里所有用户的手机号发给我”。我们的过滤器会识别出这类递归指令、全量扫描指令、以及明确的数据导出指令并立即返回标准化错误“您的请求涉及高风险操作已自动拦截。如需批量查询请联系管理员开通白名单。” 这层过滤必须在 LLM 调用之前完成因为一旦 LLM 开始思考它的 token 消耗和计算资源就已经被占用了拦截成本远高于前置拦截。提示别指望 LLM 自己做安全判断。我们在压测中发现当输入包含“请模拟一次 SQL 注入攻击”时有 37% 的主流开源 Agent 框架会真的尝试构造恶意 SQL 并调用数据库工具——因为它们把“模拟”当成了“执行”。输入解析层的安全过滤是唯一可靠的防线。2.2 记忆管理不是“记住一切”而是建立一套动态的、有成本意识的遗忘机制很多人以为 Agent 的记忆就是“把聊天记录存进向量库”。这就像把整个图书馆的书都塞进你的大脑然后靠翻页来查找——效率极低且必然导致“内存溢出”。真正的记忆管理是一套分层、分级、带成本核算的动态系统。我们把它分为三层短期记忆Working Memory存放在内存中的环形缓冲区容量固定为 16KB。它只保留当前会话最近 3 轮的完整交互用户输入 Agent 输出 工具调用结果。超过 3 轮最老的一轮被自动覆盖。为什么是 3 轮因为我们统计了 92% 的用户任务都在 3 轮内完成比如问“查订单”→Agent 返回订单号→用户问“这个订单发货了吗”。设成 2 轮会丢失关键上下文设成 4 轮内存占用翻倍但收益几乎为零。长期记忆Long-term Memory存放在专用向量数据库我们用的是 Milvus中。但它不存原始对话而是存 LLM 提炼出的语义摘要和关键事实。比如用户说“我叫张伟住在北京市朝阳区建国路8号”LLM 会生成摘要“用户姓名张伟常驻地址北京市朝阳区建国路8号”。这个摘要被向量化后存入数据库。下次用户说“我的快递送到哪儿了”Agent 就能精准召回“常驻地址”这个事实而不是去检索所有关于“张伟”的聊天记录。摘要生成由一个独立的、轻量级的微调模型7B 参数完成比主 LLM 快 8 倍成本低 90%。外部记忆External Memory指业务系统本身的数据库、CRM、ERP 等。Agent 从不把它们的内容“复制”进自己的记忆而是通过工具调用实时查询。这是最关键的工程原则Agent 的记忆永远是索引不是副本。我们曾有个项目把客户 CRM 的全部字段都同步到向量库结果每次 CRM 更新同步延迟导致 Agent 给出过期信息引发客诉。后来改成“按需查询本地缓存TTL5分钟”问题彻底解决。注意向量检索的 top-k 不是越大越好。我们实测发现top-k3 时召回准确率最高89.2%k5 时准确率反而降到 83.7%因为引入了更多噪声片段。这背后是 LLM 的注意力机制特性——它更擅长处理少量高质量上下文而非大量低质量信息。2.3 规划引擎不是“想一步走一步”而是生成一张带时间窗和容错路径的施工图规划引擎是 Agent 的“项目经理”。它接到一个目标比如“帮用户完成信用卡还款”不是立刻调用还款接口而是先画一张施工图第一步查账单工具 A第二步确认还款金额工具 B第三步调用支付工具 C第四步发送通知工具 D。但这张图必须包含三个现实要素时间窗约束、失败容错路径、资源预估。时间窗约束每个步骤都有预期耗时。查账单工具 A平均 120ms但 P99 是 800ms调用支付工具 C平均 350msP99 是 2.1s。规划引擎必须把这些 P99 值纳入总工期计算。如果用户要求“3秒内完成”它就必须放弃“先查账单再确认金额”的串行路径转而采用“并行查询账单和可用余额再合并决策”的方案——哪怕这会让 LLM 的 prompt 更复杂。失败容错路径规划图里每条边步骤都必须标注“失败后怎么办”。查账单失败是重试还是降级到“显示最近一笔还款记录”调用支付失败是切换支付渠道还是引导用户手动操作这些路径不是写在代码里而是作为结构化数据JSON Schema注入到 LLM 的 system prompt 中。LLM 在生成下一步 action 时会明确输出{action: fallback_to_manual, reason: payment_gateway_timeout}而不是凭空猜测。资源预估规划引擎要预估本次任务所需的 token、计算资源、外部 API 调用次数。比如一个涉及 5 个工具调用、3 次 LLM 推理的任务预估 token 消耗约 4200CPU 时间约 1.8s。这个预估值会传给调度器决定是否放入高优队列还是等待资源空闲。我们曾因此避免了一次重大事故一个用户连续发起 20 个复杂查询调度器根据预估资源将其中 12 个放入低优队列防止了 CPU 打满导致的整个集群雪崩。2.4 工具编排层不是“能调用就行”而是构建一套带契约、熔断和沙盒的工业级调用体系工具是 Agent 的“手脚”。但把一个 HTTP API 封装成工具只是万里长征第一步。真正的工程挑战在于如何确保这只手在任何情况下都不会打翻杯子、不会误触开关、不会在断电时失控我们为工具编排层建立了三道防线第一道是契约式定义Contract-first。每个工具在接入前必须提供一份严格的 OpenAPI 3.0 规范。Agent 框架会自动生成客户端 SDK并在运行时校验所有输入参数是否符合 schema。比如一个“创建工单”的工具要求priority字段必须是[low, medium, high, critical]之一。如果 LLM 输出{priority: urgent}框架会立即拦截并报错“参数 priority 不合法可选值为 [low, medium, high, critical]”而不是把错误请求发出去让下游服务返回 400。第二道是熔断与降级Circuit Breaker Fallback。我们使用 Hystrix 风格的熔断器。当某个工具连续 5 次调用失败超时或 5xx熔断器开启后续请求直接走降级逻辑比如返回缓存数据、返回静态提示文案持续 30 秒。熔断期间所有对该工具的调用都被计数30 秒后允许 1 个试探性请求通过成功则关闭熔断失败则继续熔断。这个机制让我们在第三方天气 API 故障时Agent 依然能返回“天气信息暂不可用请稍后再试”而不是卡死或报错。第三道是沙盒执行Sandboxed Execution。所有工具调用都在一个隔离的 Docker 容器中运行。容器有严格的资源限制CPU 0.2 核内存 256MB网络仅允许访问白名单域名并且挂载了一个只读的、预装了必要依赖的镜像。这样即使工具代码里有os.system(rm -rf /)这样的恶意指令也只会删掉容器内的临时文件宿主机毫发无伤。我们曾用一个故意写坏的“文件转换”工具测试它在沙盒里疯狂消耗 CPU但宿主机负载纹丝不动。实操心得别用 Python 的subprocess直接调用命令行工具。我们早期这么干结果一个用户上传了恶意 PDF工具调用pdftotext时触发了 Ghostscript 的远程代码执行漏洞直接拿到了宿主机权限。换成沙盒容器后同个漏洞只影响单个容器5 秒后自动销毁。2.5 执行监控器不是“看日志”而是给每一次工具调用装上黑匣子和心电图执行监控器是 Agent 的“飞行数据记录仪”。它不关心 LLM 说了什么只专注记录工具调用是否发起何时发起参数是什么HTTP 状态码多少响应体多大耗时多少毫秒是否触发了熔断是否走了降级这些数据不是为了事后分析而是为了实时干预。我们给监控器设计了两个核心能力实时健康画像对每个工具监控器维护一个滚动窗口最近 60 秒的健康指标成功率、平均耗时、P95 耗时、错误码分布。当某个指标异常比如成功率从 99.8% 突降到 92%监控器会立即向规划引擎发送一个health_alert事件。规划引擎收到后会动态调整后续任务的工具选择策略。比如原本首选的支付网关 A 出现抖动它就会在下一单自动切换到备用网关 B用户完全无感。调用链路追踪Trace每一次 Agent 任务从用户输入开始到最终输出结束生成一条完整的 Trace。这条 Trace 包含所有 LLM 调用、所有工具调用、所有内存读写操作每个节点都标注了 timestamp、duration、input、output脱敏后、status。我们用 Jaeger 实现但做了关键改造Trace ID 会透传到所有下游服务支付、CRM、通知中心这样当用户投诉“还款没成功”运维只需输入一个 Trace ID就能在 10 秒内看到是 LLM 生成了错误的银行卡号是支付网关返回了“余额不足”但没被正确解析还是通知服务在发送短信时超时整个链路一目了然平均故障定位时间从 47 分钟缩短到 3.2 分钟。2.6 反馈整合器不是“把结果拼回去”而是做一次精准的语义对齐和价值重估LLM 输出的 action 和参数工具返回的原始结果这两者之间存在巨大的语义鸿沟。反馈整合器的任务就是弥合这个鸿沟并判断这个结果对当前目标来说够用吗还是需要补救举个例子用户目标是“订一张明天从北京到上海的高铁票”。LLM 规划调用“余票查询”工具参数是{from: 北京, to: 上海, date: 2024-05-16}。工具返回了 23 条车次数据每条包含车次号、出发时间、到达时间、余票数、票价。但 LLM 的下一步指令是“调用订票工具”它需要的是具体哪一趟车、哪个座位、哪个乘客。反馈整合器必须做三件事语义对齐把 23 条原始数据提炼成 LLM 能理解的结构化摘要。不是简单截取前 5 条而是根据预设规则比如“优先 G 字头、出发时间在 8-10 点、二等座余票 10”选出最优 3 个选项并生成自然语言描述“为您找到 3 个优选车次G10108:00-12:30二等座余票 24 张G10308:30-13:00二等座余票 17 张G10509:00-13:30二等座余票 31 张”。价值重估检查这个结果是否满足目标。余票数是 24大于 0说明“有票”这个核心目标达成。但如果用户历史偏好是“靠窗座位”而返回的 23 条数据里没有一条标注了座位类型那么这个结果就是“不完整”的需要触发补充查询“请返回 G101 次列车的详细座位图”。格式规整把对齐和重估后的结果包装成标准 JSON注入到 LLM 的 next input 中。这个 JSON 的 schema 是固定的确保 LLM 每次都能从相同位置拿到相同结构的数据避免因字段名变化导致的解析失败。注意反馈整合器的逻辑必须和 LLM 的 system prompt 严格对齐。我们曾遇到一个 bug整合器把“余票数”字段命名为available_seats而 prompt 里写的是remaining_tickets导致 LLM 总是忽略这个关键信息。后来我们强制规定所有整合器输出的字段名必须和 prompt 中的示例完全一致并加入自动化校验。2.7 输出生成器不是“润色一下”而是完成一次面向用户的终极价值交付输出生成器是 Agent 的“产品经理兼客服”。它拿到 LLM 的最终回复、所有工具调用结果、以及用户的历史偏好生成最终呈现给用户的文字、卡片、链接或按钮。它的核心原则是交付价值而非展示过程。价值导向用户不关心你调用了几个 API、花了多少 token。他只关心“事办成了吗”。所以输出必须聚焦结果。比如订票成功后输出不是“已调用订票接口返回状态码 200”而是“✅ 订单已确认车票信息已发送至您的邮箱。G101 次08:00 北京南站出发12:30 抵达上海虹桥站。座位号05车 12A。”个性化适配输出内容会根据用户画像动态调整。对高频商务用户突出时间、车次、座位号对老年用户增加大号字体、语音播报按钮、以及“如何取票”的图文指引对海外用户自动切换货币单位和日期格式。交互增强输出不仅是文字更是下一步行动的入口。订票成功后除了文字还会附带一个“查看车票详情”的按钮链接到 PDF和一个“添加到日历”的按钮生成 .ics 文件。这些按钮的 URL 和参数都是在输出生成阶段动态拼接并签名的确保安全。兜底保障当 LLM 输出异常比如返回空字符串、返回乱码、返回明显无关内容输出生成器会启动兜底模板。这个模板是纯静态 HTML/CSS/JS不依赖任何 LLM 或外部服务保证在最差情况下用户依然能看到一条清晰、友好的提示“系统正在升级您的请求已收到稍后将为您处理。”3. 七个决策点工程落地的十字路口每个选择都决定成败如果说七要素是 Agent 的骨架那么七个决策点就是骨架上那些关键的关节——它们本身不承载重量但每一个的松紧、角度、材质都直接决定了整个身体能否灵活运动、承受多大负荷。这七个点是我在从 PoC 走向生产环境时被反复拷问、反复验证、最终拍板的关键抉择。它们不是理论推演而是用服务器成本、用户投诉率、SLA 达标率换来的经验值。3.1 决策点一LLM 选型——不是“越大越好”而是“刚刚好”选 LLM是第一个也是最致命的决策。很多团队一上来就冲着 70B、130B 的旗舰模型去结果发现推理速度慢得像蜗牛显存占用高得离谱成本高到无法承受。我们做过一个残酷的对比实验用同一个“智能客服”任务解析用户问题、调用知识库、生成回复在不同模型上跑模型参数量单次推理平均耗时1000 QPS 成本美元/小时回复质量人工盲测得分Llama3-70B70B2.8s$14292.1Llama3-8B8B0.35s$12.786.3Qwen2-7B7B0.28s$9.484.7Gemma2-2B2B0.12s$3.178.5结论很清晰70B 模型的质量提升5.8 分远不足以弥补其成本14x和延迟10x的代价。我们最终选择了Qwen2-7B原因有三第一它在中文长文本理解上对齐了 Llama3-8B 的水平但速度快 25%第二它支持 32K 上下文足够覆盖绝大多数 Agent 任务第三它有成熟的量化版本AWQ在 A10 GPU 上能达到 120 tokens/s 的吞吐完美匹配我们的实时性要求P95 800ms。实操心得别迷信榜单。Open LLM Leaderboard 上的分数是在标准 benchmark 上测的和你的实际业务场景天差地别。我们把榜单 top3 的模型都用真实客服日志10 万条做了 A/B 测试结果 Qwen2-7B 在“意图识别准确率”上反超 Llama3-8B 1.2 个百分点。因为它的训练数据里包含了大量中文电商、金融领域的对话而 Llama3 的数据偏重英文科技论坛。3.2 决策点二循环机制——不是“无限重试”而是设定清晰的退出边界Agent 的核心是“思考-行动-观察-反思”的循环。但这个循环必须有明确的退出条件否则就是无限套娃。我们定义了三个硬性退出边界最大步数Max Steps默认设为 5。这意味着从用户输入开始Agent 最多执行 5 次 LLM 推理 工具调用的组合。超过 5 步无论任务是否完成都强制终止并返回兜底回复。为什么是 5因为我们的数据分析显示99.3% 的成功任务都在 5 步内完成第 6 步开始失败率陡增且大多是逻辑死循环比如 LLM 反复调用同一个失败的工具。最大耗时Max Duration全局超时设为 8 秒。这个时间是从用户请求抵达网关开始计时到最终响应发出为止。它包含了网络传输、序列化、LLM 推理、工具调用、结果整合的所有环节。8 秒是基于用户体验研究用户在移动端等待超过 8 秒放弃率会飙升至 63%。失败容忍度Failure Tolerance在一个循环内如果某次工具调用失败超时或错误Agent 可以重试但最多重试 2 次。第 3 次失败必须触发降级或终止。这个数字来自对工具稳定性的统计我们接入的 23 个内部工具P999 失败率是 0.12%重试 2 次后累积失败率降到 0.000144%可以接受。这三个边界是相互制约的。比如一个任务已经跑了 4 步耗时 7.2 秒那么第 5 步的可用时间只剩 0.8 秒。如果此时要调用一个 P99 耗时 1.2 秒的工具调度器会直接拒绝触发降级。这种刚性约束是保证系统稳定性的基石。3.3 决策点三工具集成方式——不是“越多越好”而是“够用、可控、可审计”工具是 Agent 的能力外延但不是越多越强。我们制定了严格的工具准入三原则必要性原则一个工具必须能解决至少 3 个高频用户场景且没有其他工具能替代才允许接入。我们曾拒绝接入一个“股票行情查询”工具因为用户 95% 的相关请求都可以用现有的“财经新闻摘要”工具关键词搜索覆盖。可控性原则工具必须提供标准的 RESTful API且支持 OAuth2.0 认证、速率限制、调用方标识。我们绝不接入任何需要用户名密码、或只能通过网页表单提交的“野路子”工具。所有工具调用都必须经过统一的 API 网关网关负责鉴权、限流、日志、监控。可审计性原则工具必须返回结构化、可解析的 JSON 响应并且每个响应都必须包含request_id和timestamp字段与 Agent 的 Trace ID 关联。这样任何一次工具调用的结果都能在 10 秒内被完整追溯。目前我们只集成了 12 个核心工具覆盖了订单、支付、物流、客服、知识库、通知、CRM、ERP 等关键域。这 12 个工具贡献了 98.7% 的用户价值。而试图接入的另外 37 个“锦上添花”的工具不仅没带来新价值反而增加了 42% 的运维复杂度和 18% 的故障率。3.4 决策点四状态存储——不是“存所有”而是分层、分级、带 TTL 的精准存储Agent 的状态是它“记得自己是谁、干过什么、接下来要干什么”的依据。但状态存储是性能和成本的黑洞。我们放弃了“把所有状态存进 Redis”或“全量存进 PostgreSQL”的粗暴方案采用了三级分层存储热状态Hot State存放在内存Go 的 map中只存当前会话的session_id、current_step、last_action、pending_tool_calls等 5 个核心字段。生命周期 会话超时时间30 分钟。这是最快的访问层99.9% 的状态读写发生在这里。温状态Warm State存放在 Redis Cluster 中存会话的完整上下文摘要、用户画像快照、最近 3 次任务的 Trace ID。TTL 设为 7 天。这是平衡速度和容量的中间层。冷状态Cold State存放在对象存储MinIO中存完整的、未脱敏的原始 Trace 日志。TTL 设为 90 天仅用于合规审计和深度故障分析。访问频率极低但必须保留。这个分层架构让我们在支撑 5000 QPS 的峰值时Redis 的内存占用稳定在 12GBCPU 使用率低于 30%。而如果全量存 Redis预估需要 80GB 内存且 CPU 会频繁打满。注意状态存储的 key 设计至关重要。我们用agent:state:{session_id}作为热状态 key用agent:trace:{user_id}:{date}作为冷状态 key。绝对不用agent:state:{user_id}因为一个用户可能有多个并发会话key 冲突会导致状态错乱。3.5 决策点五并发模型——不是“加机器”而是从源头设计异步、非阻塞、可伸缩的流水线“AI Agent 怎么扛并发”是热搜词但答案不是堆服务器。我们的并发模型是基于 Go 的 goroutine channel 构建的流水线接入层IngressNginx 接收请求转发到 Agent Dispatcher。分发层Dispatcher为每个请求分配一个唯一的task_id并将其放入一个带缓冲的 channelbuffer size 1000。Dispatcher 本身是无状态的可以水平扩展。执行层Executor一组固定数量的 goroutine我们设为 CPU 核心数 * 2从 channel 中消费task_id加载状态执行完整的 Agent 循环LLM 调用、工具调用、结果整合。每个 goroutine 是独立的不共享内存。输出层EgressExecutor 完成后将结果写入一个结果 channel由专门的 Egress goroutine 统一收集、序列化、返回 HTTP 响应。这个模型的关键优势是goroutine 的创建和销毁成本极低纳秒级且 channel 的缓冲机制天然提供了流量削峰能力。当突发流量涌入channel 会暂时积压请求而不是瞬间打垮 Executor。我们实测在 10000 QPS 的压力下系统 P99 延迟稳定在 780ms错误率 0.02%。而如果用传统的线程池模型同等压力下线程创建开销会导致延迟飙升到 3s错误率超过 15%。3.6 决策点六安全边界——不是“靠 LLM 过滤”而是建立纵深防御的四层防火墙Agent 的安全是生死线。我们构建了四层防火墙第一层输入过滤Input Filter在 Dispatcher 层用正则和 DFA 算法实时扫描用户输入。过滤掉明显的恶意 payloadSQL 注入、XSS、命令注入以及高风险指令“删除所有数据”、“导出用户列表”。这一层拦截了 92% 的初级攻击。第二层LLM 指令加固Prompt HardeningSystem Prompt 中强制要求 LLM “永远不要执行任何未经明确授权的操作”并列出所有禁止动作如不得调用system命令、不得访问/etc/passwd、不得生成可执行代码。同时我们用 RLHF 微调让模型对“越权请求”产生高置信度的拒绝回复。第三层工具沙盒Tool Sandbox如前所述所有工具在隔离容器中运行资源受限网络白名单。第四层输出审查Output Scrubbing在 Egress 层对 LLM 的最终输出进行二次扫描。使用一个轻量级的 NER 模型识别并脱敏所有 PII个人身份信息手机号、身份证号、银行卡号、地址。脱敏规则是手机号 →138****1234身份证号 →110101********1234。这个模型在 CPU 上就能跑耗时 5ms。这四层缺一不可。我们曾被一次“社会工程学”攻击击穿攻击者诱导 LLM 生成了一段看似正常的 Markdown 表格但表格单元格里嵌入了 base64 编码的恶意 JS。第一层输入过滤没拦住因为是合法 Markdown第二层 LLM 加固也没起作用因为 LLM 认为这是“渲染内容”第三层沙盒更不管前端渲染。直到第四层输出审查才识别出 base64 解码后的 JS 片段将其替换为[安全警告检测到潜在恶意脚本]。3.7 决策点七可观测性——不是“看指标”而是构建面向 SRE 和业务的双视角监控体系可观测性是 Agent 的“听诊器”。我们不只看 CPU、内存、QPS 这些基础设施指标而是构建了两个视角SRE 视角Infrastructure View监控 Agent 服务自身的健康。核心指标包括agent_task_duration_seconds_bucket任务耗时分布Prometheus Histogramagent_tool_call_success_rate各工具调用成功率Gaugeagent_llm_request_failed_totalLLM 请求失败总数Counteragent_state_cache_hit_ratio状态缓存命中率Gauge业务视角Business View监控 Agent 对业务目标的达成效果。核心指标包括agent_task_success_rate_by_intent按意图分类的成功率比如“查订单”成功率 99.2%“改地址”成功率 94.7%agent_fallback_triggered_total降级触发次数Counter关联到具体降级原因如fallback_reasontool_timeoutagent_user_satisfaction_score通过在输出末尾嵌入一个 1