最近帮两个朋友把个人Agent脚本往生产环境搬两个人都踩了差不多的坑本地跑得好好的工具一挂成服务就开始超时、并发一高就崩、日志乱七八糟、记忆还会串。他们问我代码逻辑明明没变为什么表现判若两人我说因为你手里的东西从“个人工具”变成了“生产级 Agent”这是两个物种不是版本号的区别。这个话题最近在各社区讨论度很高尤其是“harness和agent区别”“AI Agent怎么扛并发”“Agent框架怎么选”这类热词反复出现。我结合自己从零搭Agent到支撑线上任务的经验把个人工具和生产级 Agent 的本质区别拆开讲透。这个过程里没有玄学全是工程问题。1. 个人工具和生产 Agent的边界到底在哪1.1 个人工具的典型特征先说个人工具长什么样。典型场景就是你写了一个 Python 脚本调用某个大模型 API让模型帮你整理笔记、生成周报、给邮件写摘要或者跑一个基于 MCP 的小客户端能在本地几秒钟内完成一次任务。它可能也有工具调用、有记忆、有循环甚至看起来已经很“Agent”了。但这类工具的核心假设是使用者只有一个任务规模很小环境长年不变失败可以靠人来兜底。文件写坏了重新跑一遍模型返回格式不对手动修一下API 超时了再等等或者重试一次。你在本地怎么折腾都行因为你就是系统最后一道容错机制。很多个人工具甚至没有持久化设计。今天对话的上下文存内存里进程一结束就清零。记录全存在一个本地 JSON 里路径写死。你换个目录运行它就罢工。这些在个人场景都不是问题因为你有心理预期知道哪里会坏坏了怎么修。1.2 生产级 Agent 多了什么生产级 Agent 的定义可以从几个关键词看出来多用户、全天候、无人值守、可观测、可恢复、可隔离。它要么是跑在服务器上的后台服务要么是被几十上百个调用方访问的 API 服务要么是每天深夜自动执行任务的批处理系统。“生产级”意味着你在睡觉的时候它还在跑它失败了不会有人摇醒你用户不会体谅你的本地环境。它需要自动处理上游抖动、模型服务限流、工具执行异常、数据格式变化甚至要保证大流量下的稳定性。更重要的一点生产级 Agent 的每一次决策都是要可以被追溯的。出了问题你得能回放当时的输入、模型输出、工具调用链找到那一环出了问题。个人工具只需要你自己懂就行生产工具需要团队甚至下游客户也懂。1.3 本质区别总结一句话个人工具追求的是“能做”生产级 Agent 追求的是“可靠地反复做”。“能做”衡量的是功能上线 “可靠地反复做”衡量的是稳定性、准确率、延迟、成本、安全这些工程指标。从前者到后者的跨越不取决于你的模型选多强而取决于你给这个 Agent 穿了多厚的工程铠甲。铠甲的具体内容就是下面要展开的几个核心分水岭。2. 可靠性与错误恢复从崩溃重启到自我恢复2.1 个人工具可以“崩溃重启”生产Agent不能个人工具最常见的行为模式是失败就抛异常进程退出你重启一下。Agent 里最经典的失败场景是什么模型返回了格式残缺的 JSON工具参数解析失败一个重试引发下一次失败。个人场景下你改一下 prompt 继续跑但生产环境里如果设计成“失败即结束”那每一个失败都会变成线上事故。生产级 Agent 需要在设计阶段就把故障恢复纳入主流程。核心不是“尽量不失败”而是“失败之后系统还能继续往前走或者优雅地停下来留下足够现场”。这意味着每一步都要考虑这一步失败了重试几次重试会带来副作用吗如果最终失败是否有降级方案整个工作流是否能从最近的检查点恢复我见过最典型的生产事故一个自动化运营 Agent 在批量生成内容时模型 API 连续超时脚本默认“超时重试3次”结果三个小时里把所有超时请求积压重发把 API 配额直接打满后面所有正常任务连带遭殃。这种体验在本地可能感受不到因为本地任务量太小打不爆 quota。2.2 幂等、重试和断路器生产级 Agent 必须引入三个基础可靠性模式幂等、有限重试、断路器。幂等是指同样的操作执行多次结果和只执行一次相同。LLM 调用本身天然支持重试因为提问不会改变世界状态但如果你的 Agent 里有一个“发送邮件”“扣减库存”“写入数据库”这种带副作用的工具重复执行就是事故。解决方案是给每个任务分配全局唯一的幂等键工具函数在执行前先检查这个键是否已经处理过。对 Agent 来说更聪明的做法是有副作用的工具接口做成“声明式”Agent 提交意图系统负责保证只执行一次。有限重试是说重试要设置次数上限和退避策略常见做法是最多重试2到3次退避时间指数增长比如 1s、2s、4s。这里有个关键细节重试还要区分错误类型。超时、接口抖动这种瞬时错误可以重试参数错误、鉴权失败、数据格式不合法这种确定性错误重试一万次也没用应该直接失败。断路器则是为了保护系统不被连环故障拖垮。当某个模型供应商连续返回 5xx 或者限流错误不应继续把所有请求都打到那个端点而是迅速“熔断”在一段时间内直接走备用模型或者返回降级结果让上游恢复再说。2.3 超时与 fail-fast 实战个人工具里一个 API 请求挂了你 CtrlC 就行。生产环境里没有超时的请求就是一个拿不回内存的隐型炸弹。Agent 工作流通常是多步骤的每一步都有预期延迟。LLM 调用设 30 秒超时工具调用设 10 秒超时整个流程设总超时 90 秒超过就终止并记录原因。这不是拍脑袋而是从用户体验反推的一个 Agent 任务如果超过一分半还没结果用户基本就放弃了系统应该尽早失败并通知。我踩过一个坑某段时间我们在跑一个文档处理 Agent每次案件处理需要一个很长的工作流中间有一环是调用第三方 PDF 解析服务。那个服务偶尔会hang住不返回客户端的默认超时是 120 秒于是整个工作流被拖了 2 分钟用户反馈“Agent 像死了一样”。后来把该环节超时改到 15 秒失败后直接走 OCR 备选方案整个流程的时间缩短了一半。这背后就是 fail-fast 思想宁可快速失败切换路径也不要在一条坏路上无限等待。3. 并发与资源治理为什么热词里总有“AI Agent怎么扛并发”3.1 串行调用与LLM吞吐瓶颈个人工具处理的是“一个人、一个任务”天然是串行流程没必要考虑并发。但生产场景完全不一样哪怕只是一个小团队的内部工具也会有多个用户同时提交任务。Agent 任务不是传统的“短请求”每次任务可能要调用几十次 LLM每次 LLM 调用可能耗时好几秒。如果按同步阻塞的方式写一个 worker 同时只能处理一个任务并发能力直接退化成最大线程数。很多人的第一个并发瓶颈就是这么来的FastAPI 起了个默认线程池每个进来的请求都同步等待 LLM 返回结果一压测QPS 翻车。更麻烦的是并发访问还会放大上游限流概率因为多个任务同时在同一个 API key 下打请求瞬间就把 token 速率打爆触发 429。3.2 任务队列与异步编排解决并发问题的标准做法是把“接收任务”和“执行任务”解耦。用户提交任务后系统立刻返回一个任务 ID任务被推进消息队列后台的 worker 池消费队列并异步执行 Agent 流程。用户可以通过轮询或者 WebSocket 拿执行状态。这套模式的好处是显而易见的接收任务的速度和任务执行的速度不再强耦合队列天然就是积压缓冲任务量暴涨时系统不会崩溃只会排队。队列选型有很多轻量方案是 Redis Stream 或者简单的 PostgreSQL 任务表 重型可以上 RabbitMQ 或 Kafka。我个人的经验是Agent 任务通常吞吐不大优先用 Redis Stream 就够配置简单、延迟低、可观测性好而且支持 consumer group多个 worker 可以并行消费。3.3 动态并发控制光有队列还不够你还需要控制“系统同时跑多少个 Agent 实例”。LLM 调用不是免费的并发太高不仅会打爆 token 配额而且内存、CPU、日志都会跟着涨。生产级做法是引入并发闸门维护一个全局信号量限制同时执行的 Agent 工作流数量配额打满时新任务在队列里等待。这里有个细节并发不能是静态固定值要能根据上游状态动态调整。比如某个模型服务当前延迟很高系统检测到后应该自动把并发数降下来反之则调高。这就需要一个反馈回路——读当前平均延迟、错误率、令牌桶剩余量然后调整 worker 池大小。听起来复杂但落地其实就是一个不断循环的“调节函数”。3.4 语言层面怎么选热词里有很多人问“基于 Rust 写 AI Agent”可行不可行或者“Python 框架到底行不行”。我要说句公道话并发能力的核心不是语言而是架构。Python 完全可以通过异步框架、进程池和消息队列扛起中低并发的 Agent 服务这也是大多数团队的现状。真正需要上 Rust 或 Go 的场景一般是高并发、低延迟的 Agent 运行时层比如把模型调用、工具执行、状态机的核心做成独立高性能服务外部再用 Python/Node 做编排。实际生产中常见的分层是Python/TS 做上层业务编排Rust/Go 做底层高并发运行时。比如“agent harness”这层如果对性能要求极高Rust 社区确实有一些框架在尝试把 Agent 循环做得更快、更省内存。但中小团队没必要为了追热词把整个栈换成 Rust先把架构处理好并发问题自然缓解。4. 可观测性print与链路追踪的区别4.1 个人工具的“日志”是给自己看生产的日志是给系统看个人工具的排查方式很简单print 中间变量看哪一步结果不对。但生产 Agent 的问题是你根本不知道用户触发了哪条路径、哪个工具、用了哪个模型、消耗了多少 token。特别在多轮循环里模型可能自己决定调用工具A还是工具B顺序也是动态的。这一步决策你事后看普通日志根本还原不出来。生产可观测性有三根支柱指标、日志、链路追踪。对 Agent 来说链路追踪是核心中的核心。每一次请求要分配一个全局 trace_id从用户提交任务开始贯穿 LLM 调用、工具执行、状态转移、数据库写入的每个环节。每一步都要记录父 span ID最终形成一棵完整的执行树。这样即使模型做出一个奇葩决策你也能顺着 span 树一步步看它听了什么、想了什么、调了什么、结果是什么。4.2 追踪一次Agent决策全过程我举一个实际例子。一个客服工单自动分类 Agent用户传来一张截图和三段文字。如果只有普通日志你只能看到“调用成功”或“调用失败”这种抽象结果完全不知道模型为什么最终把工单分到了“售后”而不是“销售”。但有了链路追踪一个 span 树长这样{ trace_id: tr_9f2c1a, spans: [ { name: user_request, start: 1000, duration: 2 }, { name: llm_call.gpt-4o, input_tokens: 1850, output_tokens: 420, duration: 3200 }, { name: tool_parser.extract_image, input: screenshot.png, result: order_id88321, duration: 800 }, { name: state_change.priority, from: normal, to: high }, { name: decision.classify, result: after_sales, confidence: 0.72 } ] }有了这个结构你可以直观看到 token 消耗在哪个环节最大哪一步工具解析花费时间最长模型是在什么上下文下做出的分类决策。排查问题时不需要猜只需要回放这个过程。所以生产级 Agent 建设第一步不是写业务代码而是先接入可观测基础设施哪怕一开始只是把结构化事件写到日志系统里也比将来什么痕迹都没有强。4.3 指标、成本与告警除链路之外生产级 Agent 必须围绕几个关键指标做监控任务成功率、LLM 调用延迟、工具失败率、token 消耗、队列积压长度、并发水位。这些都是运营一个 Agent 系统的“仪表盘”失去了它们你等于蒙着眼开车。其中 token 消耗常被忽略。个人脚本里 token 花个几块钱无感但生产环境每个任务动辄几千 token乘以一天几万次调用就是纯成本。你必须知道每个环节平均消耗多少哪些 prompt 浪费严重哪个模型的性价比差这样才能做成本优化。热词里“AI Agent token 是什么意思”其实就是这个基础概念文本被切分成 token 后按量计费生产级 Agent 必须把 token 消耗视为一等指标来管理。5. 记忆与状态文件存储到事件溯源5.1 个人工具的“记忆”是多一次性个人工具的记忆通常有两种形态一种是直接把历史对话一股脑塞进 prompt另一种是把对话摘要存到本地文件。它们本质上都是“尽力而为”没有版本、没有持久化、没有隔离。问题在单用户场景下不易暴露一旦多个用户共享一个 Agent 实例记忆就变成灾难用户A的消息被用户B的上下文覆盖或者所有用户的会话数据写进同一个文件互相污染。生产 Agent 的记忆需要按维度切分。最外层是用户隔离每个用户有独立的会话历史其次是会话隔离同一个用户的多个任务不能互相串再往上是全局知识库比如企业知识、产品文档这部分需要独立于对话记忆单独管理。5.2 三层状态架构我推荐的生产级记忆设计分三层第一层是短期记忆对应当前任务窗口内的上下文通常就是最近几轮对话和工具输出。这一层直接用 Redis 存储TTL 可以设短一些避免无限膨胀。第二层是长期记忆对应跨会话的用户偏好、历史决策、事实信息。这一层推荐向量数据库存储每次写入的时候做 embedding查询时做相似度召回。个人工具里你可能用本地 txt 文件记录“用户喜欢简洁回答”生产级 Agent 则需要在每次回答前动态检索相关记忆再拼进 prompt。第三层是事实状态对应 Agent 在工作流中产生的业务数据比如工单状态、订单信息、数据库记录。这层应该落到关系型数据库Agent 只通过工具接口读写不直接篡改业务系统。5.3 上下文膨胀与摘要压缩聊记忆必然要聊 token 预算。LLM 上下文窗口再大塞的内容太多也会出现两个问题质量下降和成本上升。生产级 Agent 必须像人一样“选择性记忆”。常用的方法有三种滑动窗口、摘要压缩、结构化抽取。滑动窗口只保留最近 N 轮对话超过的就被裁剪简单直接摘要压缩是把旧对话拿给一个轻量模型生成摘要然后把摘要留在上下文里结构化抽取则是直接把关键信息变成 JSON 存入状态表后续调用时查表而不是回溯原文。三种方法组合起来就能把几千轮的长期对话压缩成几百 token 的“工作记忆”同时保证关键事实不丢失。我个人的经验是摘要压缩最适合生产场景。滑动窗口容易丢掉重要决策依据结构化抽取对不确定信息束手无策而摘要可以用“逐段概括重点标记”的方式兼顾质量和成本。6. 工具编排与Harness热词背后真正的困惑6.1 为什么总有人问“harness和agent区别”最近社区热词里有一组高频问题“harness和agent区别”“agent框架与编排”“agent harness到底指什么”。我理解大家的困惑市面上概念太多Agent、Harness、Skill、Tool、Framework好像说的是同一个东西又好像不是。我的理解是这样Agent 是大脑和决策循环Harness 是承载这个大脑和循环的系统外壳。模型负责想工具负责做Harness 负责把“想”和“做”安全地连接起来。你问“Agent 和 Harness 有什么区别”本质上是问“业务逻辑和运行环境有什么区别”Agent 是业务逻辑Harness 是运行环境。没有 HarnessAgent 就是一个裸模型不能访问工具、没有记忆、没有错误恢复、没有观测。6.2 Harness 到底承担哪些职责完整的 Agent Harness 至少承担六件事模型接入统一封装不同模型供应商的 API处理鉴权、重试、超时、流式响应。工具注册与调用维护工具蓝图校验模型生成的参数执行工具并把结果回传。上下文管理组装 system prompt、动态注入记忆、控制滑动窗口和摘要。决策循环控制决定是否继续调用工具、什么时候终止、什么时候请求用户确认。鉴权与权限在工具执行前检查当前会话是否有权限调用该工具。可观测性埋点在循环的每个关键节点自动生成 span 和事件日志。把 Agent 比作赛车手Harness 就是赛车本身。赛车手再强没有变速箱、底盘、仪表盘的支撑也跑不完比赛。这也是为什么现在“Agent 框架”“Agent Harness”的话题越来越火大家逐渐意识到决定上限的往往不是模型而是整套支撑系统。6.3 工具注册、Schema校验与Skill工具层是 Harness 里最容易被低估的部分。个人脚本里写一个 function calling 只需要定义函数名和参数说明但生产环境里一个 Agent 可能同时挂几十个工具模型生成的参数随时可能缺字段、类型错误、语义越界。生产级 Harness 必须用强Schema约束工具接口比如 JSON Schema模型在调用工具前Harness 先做参数校验不合法就返回校验错误让模型重新生成。这一步能在源头拦截大部分工具调用事故。热词里“Agent Skill”指的就是工具的使用能力封装。一个 Skill 通常包含工具调用方法、适用场景说明、输入输出规范、示例。比如“将网页保存为 Markdown”的 Skill包含网页抓取、HTML 转 Markdown、图片处理三个子工具以及什么时候调用它们、参数怎么填、失败怎么兜底。把常用能力沉淀成 Skill是个人工具向生产 Agent 演进的重要一步因为这样模型不需要每次靠猜来调用工具而是直接匹配成熟的技能包。6.4 框架选型LangGraph、Dify、CrewAI怎么取舍热词里常年有“Agent框架如LangChain、Dify、CrewAI哪个好”这种问题。我只能说选框架之前先把你的任务类型想清楚。如果你的流程是强状态机比如必须先查库、再调模型、再做人工审批步骤顺序基本固定LangGraph 这种基于图的工作流引擎很合适它能把流程画出来、控制分支、插入人工节点天然适合生产级编排。如果你的目标是快速搭建对内部用户的应用不打算写太多底层代码Dify 这类低代码平台能让你在可视化界面上把 Prompt、知识库、工具流串起来部署和运维都省心。如果你是玩多角色多智能体协作希望多个专业 Agent 分工合作CrewAI 的思路更贴合它把 Agent、任务、工具组织成“团队”协作模式能让不同角色并行处理问题。我个人的建议是生产系统里别把编排逻辑完全绑定在一个大而全的框架上。底层拿 LangGraph 或者手写状态机做核心调度上层用轻量任务队列做任务分发工具层用 MCP 做统一接入。这样每一层都可以独立替换不会被框架绑架。7. 安全与权限治理工具即权限7.1 工具权限设计必须“拒绝优先”个人工具里你需要给 Agent 的 API key 往往有极高权限脚本里写着什么就执行什么。生产环境绝对不允许这样。一个能调用“写数据库”工具的 Agent如果权限边界不清晰一次模型幻觉或 prompt 注入就能造成数据灾难。生产安全的第一原则是最小权限每个 Agent、每个任务只被授予完成该任务所必需的权限多余的一律拒绝。工具权限的粒度要尽量细。给 Agent 一个“发送邮件”工具不意味着它有权把邮件发给所有人给“读数据库”工具不意味着它可以读任意表。生产 Harness 应该支持在工具执行前做一次权限校验比如以用户身份、以Agent身份、以租户维度三层过滤。这套机制在个人工具里可能显得繁琐但没有它Agent 越强大风险越大。7.2 沙箱、密钥管理、审计日志代码执行类工具必须放在隔离沙箱里。最常见的是容器模板每个任务起一个独立容器网络策略默认拒绝执行完毕即销毁。如果 Agent 需要访问外部 API通过白名单网关转发不让 Agent 直接持有关键密钥。密钥集中管理开发环境、测试环境、生产环境严格分离日志和错误信息里不得出现明文密钥。审计日志是生产级 Agent 的底线。所有工具的调用记录、参数内容、执行结果、操作者信息都要落库。哪怕业务上不需要也必须为了事后追责和安全分析而保留。我之前改造一个内部定价 Agent 时起初还没做审计上线三天后接到一个投诉说某次自动调价不合理。因为没有审计日志我们根本不知道那次调价的触发链路是什么样。后来补上了全链路审计再次出现问题时十分钟就定位到了原因。8. 从个人工具到生产 Agent 的演进实操8.1 三个演进阶段落到具体行动上把一个个人脚本演进成生产级 Agent通常要经历三个阶段。阶段一结构清晰的原型。把散落在一个文件里的逻辑拆成模块工具接口用 JSON Schema 定义模型调用抽成独立封装至少用 trace_id 贯通一次请求。这个阶段不需要引入重型基础设施重点是让“单次流程”可以被理解和测试。阶段二服务化。引入 API 层接收任务消息队列做任务缓冲任务状态落到存储日志改成结构化事件。目标是把“一个人执行一次”变成“一个服务执行很多次”。阶段三生产加固。加多实例部署、网络隔离、权限校验、指标告警、蓝绿发布、回归测试。目的是让系统没有人工看护也能长时间稳定跑。8.2 具体的演进路径以一个“把网页保存成 Markdown 再做摘要”的个人工具为例第一步把工具封装成独立函数定义好 JSON Schema。第二步用 FastAPI 包一层 HTTP 接口提交任务时返回 task_id。第三步任务不在请求里同步执行而是推入 Redis Streamworker 进程消费后异步执行。第四步把任务状态、摘要结果存到 Postgres用户可以轮询GET /task/{task_id}拿结果。第五步接入 OpenTelemetry每个任务生成 trace。第六步加上并发信号量、重试策略、断路器、备用模型。第七步给“写入文件”“访问网络”这些工具加上权限白名单部署进容器。给一个简化版异步任务代码轮廓# app.py极简结构演示生产思路 from fastapi import FastAPI import redis app FastAPI() r redis.Redis() app.post(/agent/tasks) def submit_task(payload: dict): task_id generate_id() r.xadd(agent_tasks, { task_id: task_id, payload: json.dumps(payload) }) return {task_id: task_id, status: queued} app.get(/agent/tasks/{task_id}) def get_status(task_id: str): return fetch_task(task_id)Worker 里用循环从 Stream 里读取任务执行 Agent 全流程更新状态。核心思想就一句话把同步的“调用”变成异步的“任务编排”。8.3 复盘从脚本到生产我踩过的典型过程我自己最开始做团队内部 Agent 时也天真地以为把脚本挂到服务器上就算生产了。第一周就遇到一个典型问题一个任务要连续调用模型 30 次中途模型 API 断了一次脚本只能从头开始。用户等了四十分钟最后得到一条“执行失败”的报错。后来我在工作流里加了“检查点机制”每完成一个阶段就把中间结果存到数据库。恢复时从最近检查点继续而不是从头跑。这个改动对稳定性的提升非常明显也让我意识到个人工具和系统级 Agent 的区别不是一步之差是整个思维方式的不同。9. 常见事故与排查速查9.1 生产环境典型的六个事故我把这几年遇到的典型生产事故整理成一个速查表给正在往生产方向迁移的团队参考。事故现象常见原因排查思路推荐解法任务卡死无响应某次LLM调用未设置超时查看trace中哪个span超长全链路设置分级超时同一工具被执行多遍重试逻辑未做幂等查看工具调用次数和重试记录引入幂等键和声明式工具接口上游API反复报429并发过高、无令牌桶控速观察限流错误率和并发水位加令牌桶限流动态降并发记忆互相污染未按用户/会话隔离状态查看写入状态的key结构缓存key加租户和会话维度出错后无法追溯缺链路追踪和结构化日志回放trace_id验证调用链接入OpenTelemetry统一埋点模型返回格式错乱prompt变化或模型版本切换对比新旧版本输出增加Schema输出校验和回归用例9.2 可复用的排查思路排查 Agent 问题时最忌讳一上来就“看代码”。正确顺序应该是先看 trace 和指标定位到出问题的具体环节再回放那一段的输入输出还原现场的 prompt 和工具返回最后才进入代码层面看校验和重试逻辑。也就是从现象到链路到代码而不是反过来。这里有一个值得养成的习惯给生产 Agent 长期跑一组“黄金测试集”。人为构造几十个典型场景每次发布新版本、换新模型时都用同一组测试跑一遍决策路径对比输出是否退化。个人工具没有这个约束改了一个 prompt 可能影响所有下游行为而不自知。生产 Agent 必须有这种回归护栏否则你永远不知道哪次上线“微调”悄悄引发了连锁故障。9.3 一个最重要的安全阀高风险操作必须人工确认最后想单独强调一点生产级 Agent 可以自动化但不能把“最后一道闸门”也自动化。凡是涉及资金、删除、对外发布、数据批量修改这类高风险操作一定要设计人工确认环节。个人工具里你不觉得需要因为操作者就是你你已经在流程里了生产Agent面对的可能是无人值守的系统一个误判带来的后果会被无限放大。这个“人工审批节点”可以设计在 Harness 的编排层Agent 输出操作意图系统判断属于高风险类别就把任务挂起等待指定负责人确认。等人确认后再继续执行真正有副作用的调用。这个机制我把它视为生产 Agent 的保险丝有它在你才敢放心让 Agent 去碰那些有“真实世界副作用”的东西。我做个人工具到现在最大的体会是个人工具像一个人骑车摔了爬起来接着骑生产 Agent 像一辆公交车车上坐着一群人你不能指望它摔了以后乘客自己走。所以本质区别不在“AI”两个字上而在系统工程的那层壳上。先把并发、状态、观测、权限这四件事理清楚再谈 Agent 的智能也不迟。
最近帮两个朋友把个人Agent脚本往生产环境搬两个人都踩了差不多的坑本地跑得好好的工具一挂成服务就开始超时、并发一高就崩、日志乱七八糟、记忆还会串。他们问我代码逻辑明明没变为什么表现判若两人我说因为你手里的东西从“个人工具”变成了“生产级 Agent”这是两个物种不是版本号的区别。这个话题最近在各社区讨论度很高尤其是“harness和agent区别”“AI Agent怎么扛并发”“Agent框架怎么选”这类热词反复出现。我结合自己从零搭Agent到支撑线上任务的经验把个人工具和生产级 Agent 的本质区别拆开讲透。这个过程里没有玄学全是工程问题。1. 个人工具和生产 Agent的边界到底在哪1.1 个人工具的典型特征先说个人工具长什么样。典型场景就是你写了一个 Python 脚本调用某个大模型 API让模型帮你整理笔记、生成周报、给邮件写摘要或者跑一个基于 MCP 的小客户端能在本地几秒钟内完成一次任务。它可能也有工具调用、有记忆、有循环甚至看起来已经很“Agent”了。但这类工具的核心假设是使用者只有一个任务规模很小环境长年不变失败可以靠人来兜底。文件写坏了重新跑一遍模型返回格式不对手动修一下API 超时了再等等或者重试一次。你在本地怎么折腾都行因为你就是系统最后一道容错机制。很多个人工具甚至没有持久化设计。今天对话的上下文存内存里进程一结束就清零。记录全存在一个本地 JSON 里路径写死。你换个目录运行它就罢工。这些在个人场景都不是问题因为你有心理预期知道哪里会坏坏了怎么修。1.2 生产级 Agent 多了什么生产级 Agent 的定义可以从几个关键词看出来多用户、全天候、无人值守、可观测、可恢复、可隔离。它要么是跑在服务器上的后台服务要么是被几十上百个调用方访问的 API 服务要么是每天深夜自动执行任务的批处理系统。“生产级”意味着你在睡觉的时候它还在跑它失败了不会有人摇醒你用户不会体谅你的本地环境。它需要自动处理上游抖动、模型服务限流、工具执行异常、数据格式变化甚至要保证大流量下的稳定性。更重要的一点生产级 Agent 的每一次决策都是要可以被追溯的。出了问题你得能回放当时的输入、模型输出、工具调用链找到那一环出了问题。个人工具只需要你自己懂就行生产工具需要团队甚至下游客户也懂。1.3 本质区别总结一句话个人工具追求的是“能做”生产级 Agent 追求的是“可靠地反复做”。“能做”衡量的是功能上线 “可靠地反复做”衡量的是稳定性、准确率、延迟、成本、安全这些工程指标。从前者到后者的跨越不取决于你的模型选多强而取决于你给这个 Agent 穿了多厚的工程铠甲。铠甲的具体内容就是下面要展开的几个核心分水岭。2. 可靠性与错误恢复从崩溃重启到自我恢复2.1 个人工具可以“崩溃重启”生产Agent不能个人工具最常见的行为模式是失败就抛异常进程退出你重启一下。Agent 里最经典的失败场景是什么模型返回了格式残缺的 JSON工具参数解析失败一个重试引发下一次失败。个人场景下你改一下 prompt 继续跑但生产环境里如果设计成“失败即结束”那每一个失败都会变成线上事故。生产级 Agent 需要在设计阶段就把故障恢复纳入主流程。核心不是“尽量不失败”而是“失败之后系统还能继续往前走或者优雅地停下来留下足够现场”。这意味着每一步都要考虑这一步失败了重试几次重试会带来副作用吗如果最终失败是否有降级方案整个工作流是否能从最近的检查点恢复我见过最典型的生产事故一个自动化运营 Agent 在批量生成内容时模型 API 连续超时脚本默认“超时重试3次”结果三个小时里把所有超时请求积压重发把 API 配额直接打满后面所有正常任务连带遭殃。这种体验在本地可能感受不到因为本地任务量太小打不爆 quota。2.2 幂等、重试和断路器生产级 Agent 必须引入三个基础可靠性模式幂等、有限重试、断路器。幂等是指同样的操作执行多次结果和只执行一次相同。LLM 调用本身天然支持重试因为提问不会改变世界状态但如果你的 Agent 里有一个“发送邮件”“扣减库存”“写入数据库”这种带副作用的工具重复执行就是事故。解决方案是给每个任务分配全局唯一的幂等键工具函数在执行前先检查这个键是否已经处理过。对 Agent 来说更聪明的做法是有副作用的工具接口做成“声明式”Agent 提交意图系统负责保证只执行一次。有限重试是说重试要设置次数上限和退避策略常见做法是最多重试2到3次退避时间指数增长比如 1s、2s、4s。这里有个关键细节重试还要区分错误类型。超时、接口抖动这种瞬时错误可以重试参数错误、鉴权失败、数据格式不合法这种确定性错误重试一万次也没用应该直接失败。断路器则是为了保护系统不被连环故障拖垮。当某个模型供应商连续返回 5xx 或者限流错误不应继续把所有请求都打到那个端点而是迅速“熔断”在一段时间内直接走备用模型或者返回降级结果让上游恢复再说。2.3 超时与 fail-fast 实战个人工具里一个 API 请求挂了你 CtrlC 就行。生产环境里没有超时的请求就是一个拿不回内存的隐型炸弹。Agent 工作流通常是多步骤的每一步都有预期延迟。LLM 调用设 30 秒超时工具调用设 10 秒超时整个流程设总超时 90 秒超过就终止并记录原因。这不是拍脑袋而是从用户体验反推的一个 Agent 任务如果超过一分半还没结果用户基本就放弃了系统应该尽早失败并通知。我踩过一个坑某段时间我们在跑一个文档处理 Agent每次案件处理需要一个很长的工作流中间有一环是调用第三方 PDF 解析服务。那个服务偶尔会hang住不返回客户端的默认超时是 120 秒于是整个工作流被拖了 2 分钟用户反馈“Agent 像死了一样”。后来把该环节超时改到 15 秒失败后直接走 OCR 备选方案整个流程的时间缩短了一半。这背后就是 fail-fast 思想宁可快速失败切换路径也不要在一条坏路上无限等待。3. 并发与资源治理为什么热词里总有“AI Agent怎么扛并发”3.1 串行调用与LLM吞吐瓶颈个人工具处理的是“一个人、一个任务”天然是串行流程没必要考虑并发。但生产场景完全不一样哪怕只是一个小团队的内部工具也会有多个用户同时提交任务。Agent 任务不是传统的“短请求”每次任务可能要调用几十次 LLM每次 LLM 调用可能耗时好几秒。如果按同步阻塞的方式写一个 worker 同时只能处理一个任务并发能力直接退化成最大线程数。很多人的第一个并发瓶颈就是这么来的FastAPI 起了个默认线程池每个进来的请求都同步等待 LLM 返回结果一压测QPS 翻车。更麻烦的是并发访问还会放大上游限流概率因为多个任务同时在同一个 API key 下打请求瞬间就把 token 速率打爆触发 429。3.2 任务队列与异步编排解决并发问题的标准做法是把“接收任务”和“执行任务”解耦。用户提交任务后系统立刻返回一个任务 ID任务被推进消息队列后台的 worker 池消费队列并异步执行 Agent 流程。用户可以通过轮询或者 WebSocket 拿执行状态。这套模式的好处是显而易见的接收任务的速度和任务执行的速度不再强耦合队列天然就是积压缓冲任务量暴涨时系统不会崩溃只会排队。队列选型有很多轻量方案是 Redis Stream 或者简单的 PostgreSQL 任务表 重型可以上 RabbitMQ 或 Kafka。我个人的经验是Agent 任务通常吞吐不大优先用 Redis Stream 就够配置简单、延迟低、可观测性好而且支持 consumer group多个 worker 可以并行消费。3.3 动态并发控制光有队列还不够你还需要控制“系统同时跑多少个 Agent 实例”。LLM 调用不是免费的并发太高不仅会打爆 token 配额而且内存、CPU、日志都会跟着涨。生产级做法是引入并发闸门维护一个全局信号量限制同时执行的 Agent 工作流数量配额打满时新任务在队列里等待。这里有个细节并发不能是静态固定值要能根据上游状态动态调整。比如某个模型服务当前延迟很高系统检测到后应该自动把并发数降下来反之则调高。这就需要一个反馈回路——读当前平均延迟、错误率、令牌桶剩余量然后调整 worker 池大小。听起来复杂但落地其实就是一个不断循环的“调节函数”。3.4 语言层面怎么选热词里有很多人问“基于 Rust 写 AI Agent”可行不可行或者“Python 框架到底行不行”。我要说句公道话并发能力的核心不是语言而是架构。Python 完全可以通过异步框架、进程池和消息队列扛起中低并发的 Agent 服务这也是大多数团队的现状。真正需要上 Rust 或 Go 的场景一般是高并发、低延迟的 Agent 运行时层比如把模型调用、工具执行、状态机的核心做成独立高性能服务外部再用 Python/Node 做编排。实际生产中常见的分层是Python/TS 做上层业务编排Rust/Go 做底层高并发运行时。比如“agent harness”这层如果对性能要求极高Rust 社区确实有一些框架在尝试把 Agent 循环做得更快、更省内存。但中小团队没必要为了追热词把整个栈换成 Rust先把架构处理好并发问题自然缓解。4. 可观测性print与链路追踪的区别4.1 个人工具的“日志”是给自己看生产的日志是给系统看个人工具的排查方式很简单print 中间变量看哪一步结果不对。但生产 Agent 的问题是你根本不知道用户触发了哪条路径、哪个工具、用了哪个模型、消耗了多少 token。特别在多轮循环里模型可能自己决定调用工具A还是工具B顺序也是动态的。这一步决策你事后看普通日志根本还原不出来。生产可观测性有三根支柱指标、日志、链路追踪。对 Agent 来说链路追踪是核心中的核心。每一次请求要分配一个全局 trace_id从用户提交任务开始贯穿 LLM 调用、工具执行、状态转移、数据库写入的每个环节。每一步都要记录父 span ID最终形成一棵完整的执行树。这样即使模型做出一个奇葩决策你也能顺着 span 树一步步看它听了什么、想了什么、调了什么、结果是什么。4.2 追踪一次Agent决策全过程我举一个实际例子。一个客服工单自动分类 Agent用户传来一张截图和三段文字。如果只有普通日志你只能看到“调用成功”或“调用失败”这种抽象结果完全不知道模型为什么最终把工单分到了“售后”而不是“销售”。但有了链路追踪一个 span 树长这样{ trace_id: tr_9f2c1a, spans: [ { name: user_request, start: 1000, duration: 2 }, { name: llm_call.gpt-4o, input_tokens: 1850, output_tokens: 420, duration: 3200 }, { name: tool_parser.extract_image, input: screenshot.png, result: order_id88321, duration: 800 }, { name: state_change.priority, from: normal, to: high }, { name: decision.classify, result: after_sales, confidence: 0.72 } ] }有了这个结构你可以直观看到 token 消耗在哪个环节最大哪一步工具解析花费时间最长模型是在什么上下文下做出的分类决策。排查问题时不需要猜只需要回放这个过程。所以生产级 Agent 建设第一步不是写业务代码而是先接入可观测基础设施哪怕一开始只是把结构化事件写到日志系统里也比将来什么痕迹都没有强。4.3 指标、成本与告警除链路之外生产级 Agent 必须围绕几个关键指标做监控任务成功率、LLM 调用延迟、工具失败率、token 消耗、队列积压长度、并发水位。这些都是运营一个 Agent 系统的“仪表盘”失去了它们你等于蒙着眼开车。其中 token 消耗常被忽略。个人脚本里 token 花个几块钱无感但生产环境每个任务动辄几千 token乘以一天几万次调用就是纯成本。你必须知道每个环节平均消耗多少哪些 prompt 浪费严重哪个模型的性价比差这样才能做成本优化。热词里“AI Agent token 是什么意思”其实就是这个基础概念文本被切分成 token 后按量计费生产级 Agent 必须把 token 消耗视为一等指标来管理。5. 记忆与状态文件存储到事件溯源5.1 个人工具的“记忆”是多一次性个人工具的记忆通常有两种形态一种是直接把历史对话一股脑塞进 prompt另一种是把对话摘要存到本地文件。它们本质上都是“尽力而为”没有版本、没有持久化、没有隔离。问题在单用户场景下不易暴露一旦多个用户共享一个 Agent 实例记忆就变成灾难用户A的消息被用户B的上下文覆盖或者所有用户的会话数据写进同一个文件互相污染。生产 Agent 的记忆需要按维度切分。最外层是用户隔离每个用户有独立的会话历史其次是会话隔离同一个用户的多个任务不能互相串再往上是全局知识库比如企业知识、产品文档这部分需要独立于对话记忆单独管理。5.2 三层状态架构我推荐的生产级记忆设计分三层第一层是短期记忆对应当前任务窗口内的上下文通常就是最近几轮对话和工具输出。这一层直接用 Redis 存储TTL 可以设短一些避免无限膨胀。第二层是长期记忆对应跨会话的用户偏好、历史决策、事实信息。这一层推荐向量数据库存储每次写入的时候做 embedding查询时做相似度召回。个人工具里你可能用本地 txt 文件记录“用户喜欢简洁回答”生产级 Agent 则需要在每次回答前动态检索相关记忆再拼进 prompt。第三层是事实状态对应 Agent 在工作流中产生的业务数据比如工单状态、订单信息、数据库记录。这层应该落到关系型数据库Agent 只通过工具接口读写不直接篡改业务系统。5.3 上下文膨胀与摘要压缩聊记忆必然要聊 token 预算。LLM 上下文窗口再大塞的内容太多也会出现两个问题质量下降和成本上升。生产级 Agent 必须像人一样“选择性记忆”。常用的方法有三种滑动窗口、摘要压缩、结构化抽取。滑动窗口只保留最近 N 轮对话超过的就被裁剪简单直接摘要压缩是把旧对话拿给一个轻量模型生成摘要然后把摘要留在上下文里结构化抽取则是直接把关键信息变成 JSON 存入状态表后续调用时查表而不是回溯原文。三种方法组合起来就能把几千轮的长期对话压缩成几百 token 的“工作记忆”同时保证关键事实不丢失。我个人的经验是摘要压缩最适合生产场景。滑动窗口容易丢掉重要决策依据结构化抽取对不确定信息束手无策而摘要可以用“逐段概括重点标记”的方式兼顾质量和成本。6. 工具编排与Harness热词背后真正的困惑6.1 为什么总有人问“harness和agent区别”最近社区热词里有一组高频问题“harness和agent区别”“agent框架与编排”“agent harness到底指什么”。我理解大家的困惑市面上概念太多Agent、Harness、Skill、Tool、Framework好像说的是同一个东西又好像不是。我的理解是这样Agent 是大脑和决策循环Harness 是承载这个大脑和循环的系统外壳。模型负责想工具负责做Harness 负责把“想”和“做”安全地连接起来。你问“Agent 和 Harness 有什么区别”本质上是问“业务逻辑和运行环境有什么区别”Agent 是业务逻辑Harness 是运行环境。没有 HarnessAgent 就是一个裸模型不能访问工具、没有记忆、没有错误恢复、没有观测。6.2 Harness 到底承担哪些职责完整的 Agent Harness 至少承担六件事模型接入统一封装不同模型供应商的 API处理鉴权、重试、超时、流式响应。工具注册与调用维护工具蓝图校验模型生成的参数执行工具并把结果回传。上下文管理组装 system prompt、动态注入记忆、控制滑动窗口和摘要。决策循环控制决定是否继续调用工具、什么时候终止、什么时候请求用户确认。鉴权与权限在工具执行前检查当前会话是否有权限调用该工具。可观测性埋点在循环的每个关键节点自动生成 span 和事件日志。把 Agent 比作赛车手Harness 就是赛车本身。赛车手再强没有变速箱、底盘、仪表盘的支撑也跑不完比赛。这也是为什么现在“Agent 框架”“Agent Harness”的话题越来越火大家逐渐意识到决定上限的往往不是模型而是整套支撑系统。6.3 工具注册、Schema校验与Skill工具层是 Harness 里最容易被低估的部分。个人脚本里写一个 function calling 只需要定义函数名和参数说明但生产环境里一个 Agent 可能同时挂几十个工具模型生成的参数随时可能缺字段、类型错误、语义越界。生产级 Harness 必须用强Schema约束工具接口比如 JSON Schema模型在调用工具前Harness 先做参数校验不合法就返回校验错误让模型重新生成。这一步能在源头拦截大部分工具调用事故。热词里“Agent Skill”指的就是工具的使用能力封装。一个 Skill 通常包含工具调用方法、适用场景说明、输入输出规范、示例。比如“将网页保存为 Markdown”的 Skill包含网页抓取、HTML 转 Markdown、图片处理三个子工具以及什么时候调用它们、参数怎么填、失败怎么兜底。把常用能力沉淀成 Skill是个人工具向生产 Agent 演进的重要一步因为这样模型不需要每次靠猜来调用工具而是直接匹配成熟的技能包。6.4 框架选型LangGraph、Dify、CrewAI怎么取舍热词里常年有“Agent框架如LangChain、Dify、CrewAI哪个好”这种问题。我只能说选框架之前先把你的任务类型想清楚。如果你的流程是强状态机比如必须先查库、再调模型、再做人工审批步骤顺序基本固定LangGraph 这种基于图的工作流引擎很合适它能把流程画出来、控制分支、插入人工节点天然适合生产级编排。如果你的目标是快速搭建对内部用户的应用不打算写太多底层代码Dify 这类低代码平台能让你在可视化界面上把 Prompt、知识库、工具流串起来部署和运维都省心。如果你是玩多角色多智能体协作希望多个专业 Agent 分工合作CrewAI 的思路更贴合它把 Agent、任务、工具组织成“团队”协作模式能让不同角色并行处理问题。我个人的建议是生产系统里别把编排逻辑完全绑定在一个大而全的框架上。底层拿 LangGraph 或者手写状态机做核心调度上层用轻量任务队列做任务分发工具层用 MCP 做统一接入。这样每一层都可以独立替换不会被框架绑架。7. 安全与权限治理工具即权限7.1 工具权限设计必须“拒绝优先”个人工具里你需要给 Agent 的 API key 往往有极高权限脚本里写着什么就执行什么。生产环境绝对不允许这样。一个能调用“写数据库”工具的 Agent如果权限边界不清晰一次模型幻觉或 prompt 注入就能造成数据灾难。生产安全的第一原则是最小权限每个 Agent、每个任务只被授予完成该任务所必需的权限多余的一律拒绝。工具权限的粒度要尽量细。给 Agent 一个“发送邮件”工具不意味着它有权把邮件发给所有人给“读数据库”工具不意味着它可以读任意表。生产 Harness 应该支持在工具执行前做一次权限校验比如以用户身份、以Agent身份、以租户维度三层过滤。这套机制在个人工具里可能显得繁琐但没有它Agent 越强大风险越大。7.2 沙箱、密钥管理、审计日志代码执行类工具必须放在隔离沙箱里。最常见的是容器模板每个任务起一个独立容器网络策略默认拒绝执行完毕即销毁。如果 Agent 需要访问外部 API通过白名单网关转发不让 Agent 直接持有关键密钥。密钥集中管理开发环境、测试环境、生产环境严格分离日志和错误信息里不得出现明文密钥。审计日志是生产级 Agent 的底线。所有工具的调用记录、参数内容、执行结果、操作者信息都要落库。哪怕业务上不需要也必须为了事后追责和安全分析而保留。我之前改造一个内部定价 Agent 时起初还没做审计上线三天后接到一个投诉说某次自动调价不合理。因为没有审计日志我们根本不知道那次调价的触发链路是什么样。后来补上了全链路审计再次出现问题时十分钟就定位到了原因。8. 从个人工具到生产 Agent 的演进实操8.1 三个演进阶段落到具体行动上把一个个人脚本演进成生产级 Agent通常要经历三个阶段。阶段一结构清晰的原型。把散落在一个文件里的逻辑拆成模块工具接口用 JSON Schema 定义模型调用抽成独立封装至少用 trace_id 贯通一次请求。这个阶段不需要引入重型基础设施重点是让“单次流程”可以被理解和测试。阶段二服务化。引入 API 层接收任务消息队列做任务缓冲任务状态落到存储日志改成结构化事件。目标是把“一个人执行一次”变成“一个服务执行很多次”。阶段三生产加固。加多实例部署、网络隔离、权限校验、指标告警、蓝绿发布、回归测试。目的是让系统没有人工看护也能长时间稳定跑。8.2 具体的演进路径以一个“把网页保存成 Markdown 再做摘要”的个人工具为例第一步把工具封装成独立函数定义好 JSON Schema。第二步用 FastAPI 包一层 HTTP 接口提交任务时返回 task_id。第三步任务不在请求里同步执行而是推入 Redis Streamworker 进程消费后异步执行。第四步把任务状态、摘要结果存到 Postgres用户可以轮询GET /task/{task_id}拿结果。第五步接入 OpenTelemetry每个任务生成 trace。第六步加上并发信号量、重试策略、断路器、备用模型。第七步给“写入文件”“访问网络”这些工具加上权限白名单部署进容器。给一个简化版异步任务代码轮廓# app.py极简结构演示生产思路 from fastapi import FastAPI import redis app FastAPI() r redis.Redis() app.post(/agent/tasks) def submit_task(payload: dict): task_id generate_id() r.xadd(agent_tasks, { task_id: task_id, payload: json.dumps(payload) }) return {task_id: task_id, status: queued} app.get(/agent/tasks/{task_id}) def get_status(task_id: str): return fetch_task(task_id)Worker 里用循环从 Stream 里读取任务执行 Agent 全流程更新状态。核心思想就一句话把同步的“调用”变成异步的“任务编排”。8.3 复盘从脚本到生产我踩过的典型过程我自己最开始做团队内部 Agent 时也天真地以为把脚本挂到服务器上就算生产了。第一周就遇到一个典型问题一个任务要连续调用模型 30 次中途模型 API 断了一次脚本只能从头开始。用户等了四十分钟最后得到一条“执行失败”的报错。后来我在工作流里加了“检查点机制”每完成一个阶段就把中间结果存到数据库。恢复时从最近检查点继续而不是从头跑。这个改动对稳定性的提升非常明显也让我意识到个人工具和系统级 Agent 的区别不是一步之差是整个思维方式的不同。9. 常见事故与排查速查9.1 生产环境典型的六个事故我把这几年遇到的典型生产事故整理成一个速查表给正在往生产方向迁移的团队参考。事故现象常见原因排查思路推荐解法任务卡死无响应某次LLM调用未设置超时查看trace中哪个span超长全链路设置分级超时同一工具被执行多遍重试逻辑未做幂等查看工具调用次数和重试记录引入幂等键和声明式工具接口上游API反复报429并发过高、无令牌桶控速观察限流错误率和并发水位加令牌桶限流动态降并发记忆互相污染未按用户/会话隔离状态查看写入状态的key结构缓存key加租户和会话维度出错后无法追溯缺链路追踪和结构化日志回放trace_id验证调用链接入OpenTelemetry统一埋点模型返回格式错乱prompt变化或模型版本切换对比新旧版本输出增加Schema输出校验和回归用例9.2 可复用的排查思路排查 Agent 问题时最忌讳一上来就“看代码”。正确顺序应该是先看 trace 和指标定位到出问题的具体环节再回放那一段的输入输出还原现场的 prompt 和工具返回最后才进入代码层面看校验和重试逻辑。也就是从现象到链路到代码而不是反过来。这里有一个值得养成的习惯给生产 Agent 长期跑一组“黄金测试集”。人为构造几十个典型场景每次发布新版本、换新模型时都用同一组测试跑一遍决策路径对比输出是否退化。个人工具没有这个约束改了一个 prompt 可能影响所有下游行为而不自知。生产 Agent 必须有这种回归护栏否则你永远不知道哪次上线“微调”悄悄引发了连锁故障。9.3 一个最重要的安全阀高风险操作必须人工确认最后想单独强调一点生产级 Agent 可以自动化但不能把“最后一道闸门”也自动化。凡是涉及资金、删除、对外发布、数据批量修改这类高风险操作一定要设计人工确认环节。个人工具里你不觉得需要因为操作者就是你你已经在流程里了生产Agent面对的可能是无人值守的系统一个误判带来的后果会被无限放大。这个“人工审批节点”可以设计在 Harness 的编排层Agent 输出操作意图系统判断属于高风险类别就把任务挂起等待指定负责人确认。等人确认后再继续执行真正有副作用的调用。这个机制我把它视为生产 Agent 的保险丝有它在你才敢放心让 Agent 去碰那些有“真实世界副作用”的东西。我做个人工具到现在最大的体会是个人工具像一个人骑车摔了爬起来接着骑生产 Agent 像一辆公交车车上坐着一群人你不能指望它摔了以后乘客自己走。所以本质区别不在“AI”两个字上而在系统工程的那层壳上。先把并发、状态、观测、权限这四件事理清楚再谈 Agent 的智能也不迟。
