几个月前我把自己花两周写好的智能体demo拿给团队看。整个流程是这样的用户说一句话程序调用一次大模型模型吐出一个JSON程序去查一下天气再把结果拼回给模型最后输出一段自然语言。演示很顺利当时我觉得这就是AI Agent的正确姿态。结果技术评审第一个问题就把我问住了“同时来50个请求每个要串行调三次模型你准备怎么控制延迟和成本”这个问题其实戳中了很多AI Agent项目的通病Demo跑通只能证明“模型知道要调工具”行业级产品还要证明“模型调工具之后不会出错、不会超时、不会被恶意输入带偏、出问题能立刻定位”这完全是另一套工程问题。这篇文章想把仓库从零搭到能交付、能压测、能维护的完整过程拆开来讲。如果你正在做客服、数据分析、流程自动化或者企业内部助手这类行业级智能体这个仓库的拆分思路能给你直接参考就算你只是想把个人助理项目做得更健壮里面很多细节也值得照抄。1. 起点如何定义“行业级”Agent的三层边界1.1 先给自己泼一盆冷水Demo和产品之间的距离很多团队立项时喜欢说“我们要做一个Agent”但目标到底是一周做完技术验证还是半年后支撑几百个真实用户两者选型和设计完全不是一回事。我见过太多项目拿着一个“模型工具调用”的demo去汇报结果一接真实业务就断了真实用户的一句话里订单查询、退款申请、物流投诉往往同时出现单个Function Call根本承载不了这种多意图场景更别提权限隔离、敏感信息脱敏、模型乱调用工具这些在生产环境必须解决的问题。这个仓库的前期调研阶段我把“行业级”拆成了三层边界来约束自己业务边界Agent只负责哪几个业务域哪些动作允许自主执行哪些必须转人工工程边界要做到几个九的可用性并发上限是多少单请求延迟预算多少安全边界工具访问权限怎么隔离哪些参数需要对模型隐藏失败重试机制会不会被用来刷接口这三层边界确定之前任何代码都是白写。它们决定了后续的每一个技术选型。比如业务边界决定Planner规划器的prompt设计工程边界决定并发模型和缓存策略安全边界决定工具网关的校验逻辑。1.2 行业级Agent的六项硬性指标把上面三层边界落到执行层面我整理了一张验收清单每一项都是Demo阶段不太会关注、生产阶段又绕不开的硬指标维度Demo要求行业级要求可用性99%左右挂了重启99.9%以上自动恢复并发单用户单会话50并发会话稳定运行可观测性print日志全链路追踪中间决策可回放安全无鉴权工具白名单、权限隔离、参数校验状态管理会话状态放内存持久化存储支持恢复和横向扩容升级迭代改代码重新部署配置化调整灰度发布每一项背后都有具体成本。举个最容易被低估的例子可观测性。Demo阶段用print看输出生产环境一个Agent会话至少要经过“意图识别→规划→工具调用→结果汇总→回复生成”五六个环节任何一个环节出错你都要能还原当时模型的输入输出和工具返回结果否则线上问题就只能靠猜。这个仓库在建仓第一天就引入了结构化日志和链路追踪后面排查问题的效率完全不一样。1.3 全仓库结构总览第三层边界确定之后仓库目录也就顺理成章地定下来了。我按照“入口—编排—执行—记忆—安全—可观测”六个方向来组织代码避免把Agent逻辑全部堆在同一个目录里后期维护会很痛苦agent-repo/ ├── gateway/ # 请求入口鉴权、限流、用户上下文解析 ├── orchestrator/ # 编排层规划、决策、循环控制 ├── executor/ # 执行层工具注册、调用、结果解析 ├── memory/ # 记忆模块短长期记忆的存取 ├── tools/ # 工具集每个业务工具独立成包 ├── security/ # 权限校验、输入过滤、脱敏 ├── observability/ # 日志、追踪、指标采集 └── deploy/ # 容器编排、配置模板、压测脚本这个结构不是一开始就长这样是重构三轮之后的最终形态。最初我把规划逻辑和工具执行代码写在同一个文件里结果模型输出格式一变整个文件都要动。拆成独立模块之后改动范围被限制在单个目录内部这对后期迭代非常重要。2. 架构选型为什么我没直接从LangChain上手2.1 备选方案的取舍搭建这个仓库之前我翻遍了当时能用的Agent开源框架也对着评测博客做了不少功课最后在“全盘使用现成框架”和“完全自研”之间做了个折中——这也是我在实际操作后比较推荐的路线。先说为什么没有直接依赖某个编排框架的全套能力。问题不在于框架本身而是框架抽象层级太多真到定制的时候你经常要绕过它的设计意图去改底层反而比从零写一个薄层还累。像Agent下一步该调用一个搜索工具还是两个业务工具这种逻辑如果下沉到框架层面框架升级一次就要重新适配一次线上的稳定性也会因此受影响。LlamaIndex则是检索增强侧的能力比较强和我的核心场景多工具自主决策匹配度一般。最后我选择用LangChain的LCEL做底层组件但编排层自己写只保留真正需要的“需求-规划-执行”三步循环。表格对比一下我当时在备选方案之间怎么权衡的方案优点缺点我的取舍全盘使用编排框架自带工具、记忆、Agent chain抽象重、定制难、升级适配成本高不采用全盘方案框架自定义组件生态好、开发快仍然受框架约束保留LCEL做底层协议完全自研完全可控重复造轮子作为辅助方案自研编排复用组件核心逻辑可控生态可用需要额外维护编排层最终采用这套组合下来收益是明显的规划、循环、记忆这几个核心环节完全在我掌控范围内而请求大模型、解析流式输出这些通用工作又不用自己重复实现。2.2 仓库的核心模块职责架构最终落地成四个核心模块Gateway、Orchestrator、Executor、Memory。Gateway负责所有外部请求的入口和处理鉴权、限流、用户身份解析、会话恢复。它不参与任何Agent决策只做流量控制和安全兜底。Orchestrator是整个Agent的“大脑”承担三件事意图拆解、步骤规划、循环控制。它根据用户输入和当前记忆决定下一步是继续调用工具、追问用户还是直接生成最终回复。这个模块里最核心的是一个循环控制器模型每轮输出一个决策循环器判断是否该停、该继续、该转人工。Executor是工具能力的“手”所有业务工具都在这里注册。它不关心Agent为什么要调用某个工具只负责拿到参数后执行并返回结构化结果。我接的业务工具包括订单查询、库存检查、政策查询、物流跟踪等每个工具都做参数校验、权限校验、结果格式化。Memory负责记忆的存取分三层实现具体会在第三章展开。Gateway和Memory之间没有直接交互所有模块间的数据都通过标准请求上下文传递避免隐式依赖。2.3 一次请求的完整数据流为了讲清楚各模块怎么配合这里列一个真实的用户请求链路比如用户问“帮我查一下订单A07的物流情况”Gateway收到请求做鉴权、限流根据用户session_id恢复记忆上下文生成一个全局trace_id。Orchestrator把用户问题和记忆快照组装成模型输入向模型发送第一轮请求。模型返回决策调用物流查询工具参数为订单号“A07”。Orchestrator把决策交给ExecutorExecutor做参数校验、权限校验后调用真实的物流服务。Executor拿到物流轨迹结构化成JSON返回给Orchestrator。Orchestrator将工具结果写回记忆再次组装模型输入发第二轮请求。模型认为信息已足够生成最终回复“物流已到XX中转站”Orchestrator把回复返回给Gateway。Gateway把完整链路日志写入追踪系统返回给用户。整个链路里所有模块都围绕同一个trace_id记录日志任何一个环节异常都能快速定位。这也是我在评审被问到“50个并发怎么排查问题”之后最坚决要补上的能力。2.4 为什么编排层必须薄这次架构设计里我想特别强调一个经验编排层一定要薄。所谓“薄”就是Orchestrator只做决策流转和循环控制不掺入具体业务判断。业务规则可以放在prompt里或者工具代码里但不能散落在编排逻辑里。举个例子某个流程曾经需要“如果订单金额超过5000元必须转人工审核”。一开始我把这个判断写在了Orchestrator的if分支里最后发现这个规则在不同业务方有完全不同的口径改一处就要动核心逻辑非常难受。后面重构时我把这类规则统一提到prompt的system指令里让模型自己根据约束做决策编排层只提供“转人工”这个出口不再判断金额大小。编排层薄了之后业务的变动就变成了prompt配置的调整代码本身的改动量大幅减少这也直接提升了后面迭代的速度。3. 核心实现从工具定义到自主决策的闭环3.1 工具协议标准化让所有能力长成一个样Agent仓库里第一个要定下来的是工具调用的协议。不管底层接的是订单API、物流API还是内部知识库在模型看来所有工具都应该是同一种描述格式这样才能让模型在多种工具之间做选择。我用的是JSON Schema风格的工具定义这是大模型服务商普遍支持的格式也方便直接注入prompttool_schema { name: query_logistics, description: 根据订单号查询物流轨迹返回到达中转站列表, parameters: { type: object, properties: { order_id: {type: string, description: 订单号格式为字母数字}, user_id: {type: string, description: 用户唯一标识} }, required: [order_id, user_id] } }每个工具都遵循三要素namedescriptionparameters。description尤其关键我吃过不少亏。最初给工具写描述很随意结果模型经常在几个相似工具之间选错后来我把description写得像给实习生交代任务一样具体比如“当用户询问包裹到哪了、什么时候到货时使用这个工具”错选率立刻降了下来。类似的经验现在已经成为我做工具描述时的硬性要求。参数类型这块还必须再做一层程序化的校验不能完全依赖模型输出。入库前用Pydantic模型做强制类型检查防止模型传入类型错误甚至带着多余字段请求工具接口from pydantic import BaseModel class QueryLogisticsParams(BaseModel): order_id: str user_id: str3.2 不要迷信长上下文记忆要分三层网上很多Demo都在吹“长上下文一把梭”但行业级项目里上下文越长模型越容易抓不住重点token成本涨得还很吓人。所以这个仓库把记忆拆成了三层记忆层存储位置生命周期作用短期记忆会话内变量一次会话当前对话轮次、临时草稿工作记忆Redis单任务执行期任务状态、已调用工具、中间结果长期记忆向量数据库跨会话用户偏好、历史关键事实、业务标签短期记忆对应的是模型上下文窗口里的对话内容每轮对话结束就更新。工作记忆是给Orchestrator做任务追踪用的里面保存了当前目标、已经调用过哪些工具、执行到第几步万一中途挂了下一轮请求可以从工作记忆恢复而不是从头开始。长期记忆负责跨会话知识沉淀比如用户是VIP客户、上次投诉过物流问题这些信息通过向量检索在每次会话开始时注入prompt。三层的核心区别是“谁访问、活多久、存什么格式”。短期记忆只有当前请求能访问工作记忆限定了任务范围长期记忆则用向量检索做语义召回。层与层之间不要互相越权否则记忆管理和清理会变得非常痛苦。3.3 循环控制防止Agent自己跑飞Agent的自主性是把双刃剑。有一次测试中模型面对一个模糊请求时反复调用工具既不继续问用户也不终止白白烧了很多token。从那之后我就把循环控制阈值当成仓库里的强制配置项来对待。我实现了一个AgentLoop控制器核心参数有四个最大步数、最大费用、置信度阈值、重复动作容忍度class AgentLoop: def __init__(self): self.max_steps 6 # 单次任务最大模型调用轮数 self.max_cost_usd 0.5 # 单次会话费用上限 self.confidence_threshold 0.6 # 决策置信度阈值 self.repeat_action_limit 2 # 同一动作连续调用上限 def should_stop(self, ctx): if ctx.steps self.max_steps: return True, max_steps_reached if ctx.cost_usd self.max_cost_usd: return True, cost_limit_reached if ctx.last_confidence self.confidence_threshold: return True, low_confidence return False, 这几个参数的设定逻辑并不复杂客服类场景平均3到5步就能完成一次查询所以max_steps设为6留出余量费用上限根据单次模型调用成本乘以预估步数来定而置信度阈值尤其关键比如工具调用结果和用户问题对不上时就必须停下来追问不然模型会顺着错误结果继续胡说。另一个设置是重复动作容忍度当模型连续两次对同一个工具发起完全相同的调用基本可以判定陷入了循环这时候就强制转人工或者直接终止。这个机制让线上不再出现“僵尸会话”一直空转的问题。3.4 上下文压缩别让历史消息把关键信息挤掉你可能会想既然记忆分了三层那模型输入里每次都塞全部历史不就好了实测下来只要对话超过十几轮模型的注意力就会被过时的信息分散甚至把早期的一条无关消息当成当前指令执行。所以我在Orchestrator里加了一个上下文压缩器当对话轮次超过10轮就把历史对话压缩成一段摘要而不是原样拼进prompt。压缩的关键在于“保留什么”。经过多次尝试我的做法是指定压缩时优先保留四类信息用户明确的意图标签、已经确认的事实订单号、手机尾号、时间范围、已完成动作的结果摘要、所有system级约束。尤其最后一条很多压缩方案容易把“金额必须脱敏”这类安全约束压没了导致模型在后续轮次做出违规操作。这里我在压缩逻辑里做了强约束系统指令块永不参与压缩始终原样保留在prompt最前面。def compress_history(messages: list, system_block: str): # system_block 原样保留 compressed_history summarize(messages[1:]) # 其他消息做摘要 return [system_block] compressed_history基于这套实现即使对话进行到30多轮模型也不会丢掉最开始的安全要求长对话漂移的问题在实际压测中大幅下降。4. 多Agent并发与协作的工程解法4.1 并发模型的选择异步成为主线说完单Agent的内部闭环还要处理真实场景里最头疼的问题多个用户同时发起会话时仓库怎么扛住这个仓库的运行环境是Python而Agent任务的核心IO是大模型接口调用和业务API调用都属于典型的高延迟IO密集型操作。如果按同步方式写一个worker串行处理一个完整会话整个请求队列很快就堵死。我最终选择的是asyncio httpx的方式让每个Agent会话在IO等待期间让出控制权这样单个worker就能同时承载十几个会话。实测下来单实例4核8G在50个并发会话的压力下总体吞吐量比同步实现提升了接近6倍。不过有一点需要特别说明工具执行阶段如果涉及CPU密集型的计算比如文档解析、大量数据聚合这部分不能放在事件循环里要扔到单独的进程池去跑否则一个重工具调用会阻塞后面所有会话。我在Executor里做了区分——IO型的工具用异步协程CPU型的工具走进程池两类工具互不干扰。4.2 隔离、超时与熔断子Agent失控时的应对策略并发场景下最怕的就是一个失控的Agent拖垮整体。我在这块设计了三级保护。第一级是隔离每个用户会话独立运行在各自的Agent实例里会话之间的记忆、工作状态完全隔离。会话之间如果需要共享用户画像走内存数据库避免某个Agent状态污染到其他会话。第二级是超时每个工具调用单次最长10秒整个Agent会话最长60秒。超时后立即返回错误并把控制权交回给用户而不是无限等待。我在网关层用asyncio.wait_for实现所有配置都可以按业务方调整。第三级是熔断当某个工具连续失败超过阈值比如10秒内连续失败5次熔断器将被打开后续对该工具的调用直接快速失败不再执行真实请求。这在接第三方物流服务时特别重要——第三方服务一抖动如果不熔断所有会话都会卡在慢调用上然后一堆超时重试把下游彻底打挂。熔断参数按生产环境压力测试结果调整过一波最后落在比较合适的口径上参数初始值压测后调整值单工具超时15秒10秒会话总超时120秒60秒熔断失败阈值10次/30秒5次/10秒熔断恢复时间30秒15秒4.3 可观测性让Agent的每一步决策可回放前面提到过可观测性被严重低估这里详细讲一下我最终落地的方案。每个请求从Gateway进入时都会生成一个全局trace_id整个链路的所有模块都会带上这个trace_id记录结构化日志。关键日志点包括模型输入prompt摘要、模型返回的决策动作、工具调用的参数和结果、循环控制器的停止原因、生成的最终回复。除了日志关键指标还会上报到监控系统做实时告警指标包括单次会话延迟、工具调用成功率、模型调用tokens消耗、转人工率。这里有一个非常重要的经验一定要记录“模型为什么做出这个决策”而不只是记录结果。只记录“调用了订单查询工具”是不够的还要记录当时模型看到了哪些上下文、置信度是多少、上一轮工具返回了什么。这些信息组合起来才能在事后完整还原Agent的思考链。我见过很多团队只记录最终完成情况的日志问题一旦出现才发现整个链路中间过程一片空白根本无从排查。5. 实测复盘模型不按套路出牌时的三处修复手段5.1 解析失败模型输出了“看起来像JSON但又不是”的内容仓库上线后的第一周线上监控就报了一个指标模型工具调用解析失败率高达3.5%。点开日志看问题五花八门工具名少了几个字符比如查“query_logistics”输成“query_logistic”。参数类型不对order_id传成整数而不是字符串。偶尔还有多余的尾逗号、尾部文本粘在JSON后面。最初的修复方案是让模型重新生成一次但实测中第二次生成的格式反而更混乱。后来我改成了“解析失败后把错误信息一并拼回prompt让模型基于错误做修正”的策略同时保留程序化兜底重试一次后仍然解析失败就不再调模型直接回退为多轮追问请用户重新表述。这样既给了模型修正机会也限制了无休止的自我反复。代码层面我在Executor入口加了一层统一的参数校验器模型输出先走JSON解析再走Pydantic校验两个环节都失败才触发重试。实施两周后解析失败率从3.5%降到0.4%以下因为这个机制从一开始就把格式问题识别在了最前端。5.2 幻觉导致的工具错调白名单与评分阈值另一类让人头疼的问题是模型“一本正经地用错了工具”。最典型的案例是仓库里根本没有“共享文档搜索”这个工具但模型在回答某类问题时竟然会臆想出这个工具名并多次尝试调它。日志里能清楚地看到模型自己杜撰了一个工具调用然后被Executor拒绝之后又再杜撰一次循环了好几次才停。这个问题的根因是模型对工具列表的理解产生了幻觉。我当时做了两个事情一是在工具注册表里加了白名单校验所有工具调用必须在启动时注册过的工具集中否则直接判为非法调用并给模型返回一个固定提示“该工具不存在请从工具列表中选择”。二是给工具调用增加了置信度评分。模型在输出决策的同时会给出一个置信度数值低于阈值的调用会被标记为“低置信度调用”此时Orchestrator会选择转成自然语言反问用户而不是强制执行工具。这两个手段叠加之后工具错调率下降了一个数量级。5.3 长对话漂移上下文越长越容易忘掉约束第三个问题发生在一次模拟长对话测试里某位“用户”在对话进行到第12轮时开始试探性地要求“不要显示金额但保留订单号”而模型竟然真的照做了。原因是对话历史把system指令挤到了非常靠后的位置模型在生成时注意力被近期对话主导完全忽略了一开始的安全约束。之前我在3.4节提到的“system约束永不压缩”就是为了解决这个问题。修复后安全约束始终站在prompt最前面模型每轮都会看到“金额必须脱敏”等指令长对话漂移率也明显下降。这也是一个很重要的设计决策在压缩历史的时候安全规则优先级永远高于对话历史本身。5.4 排查Agent问题时的正确打开方式经过这段时间的连续踩坑我总结出排查这类问题的一个核心思路不要只看最终回复要看中间决策过程。一个用户问“订单到哪了”如果模型最终输出了正确回复你会觉得一切正常。但中间过程可能是模型先错误地调用了库存查询工具得到一个无关结果然后又调用了物流查询工具才得到正确结果。如果只看最终回复这一连串的浪费和潜在风险根本不会被发现。所以在监控面板上每一次工具调用都会出现在链路视图里任何一个多余的调用、报错的调用、低置信度的调用都会被标记成黄色或红色。Agent问题的排查方式从“看回复猜原因”变成了“看链路找问题”效率完全不同。6. 部署与压测把仓库从单机搬上容器化6.1 延迟预算与资源估算到了部署环节第一个要明确的就是延迟预算。Agent服务和普通接口不一样一次请求通常要串行调用多次模型每一次模型调用都可能需要一两秒甚至更久。我在需求阶段定的目标是单次会话P95延迟不超过10秒超出部分需要开发单独提示或者转人工。基于这个预算做资源估算公式大概是这样的单并发预估延迟 模型调用次数 × 模型单次调用P95延迟 工具执行总耗时以客服场景为例平均3次模型调用每次P95大约2秒工具执行平均1秒加起来约7秒接近预算上限。如果再部署时要留出30%冗余两个并发请求就会出现排队。基线这就出来了。根据这个估算一个4核8G的实例可以承载约30到50个并发会话再往上就需要水平扩容。Redis负责记忆存储因此在扩容时不用做会话绑定任意一个实例都能接起用户请求这让我部署时不需要引入复杂的会话粘滞机制。6.2 降级策略与模型路由模型服务是Agent链路里最关键的依赖也是不可控性最高的环节。所以仓库里做了模型路由和降级策略默认使用主力模型当它响应变慢或者频繁报错时自动把请求切到低延迟备用模型备用模型虽然能力稍弱但在简单任务上响应稳定能够兜住大部分流量。另外还有一些低级别的降级手段常见问题先走缓存直接出答案不进入Agent遇到模型完全不可用的极端情况网关会返回一个降级提示引导用户走人工客服或者标准表单。这些策略加载在Gateway里通过配置中心动态调整不需要发版。缓存这个点容易被人忽略但在真实场景里作用非常大。我整理了一批高频问题把它们的最终回复缓存起来命中缓存时延迟从几秒直接降到几十毫秒。缓存命中率稳定在20%左右别小看这20%它把整体的可用性和成本都优化了一大截。6.3 压测数据与参数调优最后说压测。我用容器跑了一套压测脚本模拟用户并发进入、提问、等待回复的完整过程。压测的主要目标是找到并发上限和参数瓶颈而不是跑一个好看的数字。第一轮压测结果让我把异步worker数从默认的20提高到了40因为发现CPU和内存占用都还有余量同时Redis连接池成了瓶颈。第二轮压测暴露出工具超时设置偏长的问题于是把超时从15秒调到了10秒并把重试次数从3次降为2次P99延迟因此下降了不到一秒。最终一版运行在单个4核8G实例上的压测数据大致如下并发数P95延迟P99延迟CPU占用内存占用101.8秒2.6秒32%41%303.1秒4.7秒68%59%505.4秒8.9秒87%76%708.2秒15秒98%88%从表格能看得很清楚50并发是相对安全的边界70并发时P99已经突破15秒明显不可用。所以线上我按单实例50并发设置限流超出部分排队等待。这个数字成了后面扩容的重要依据。6.4 容器化部署与配置管理部署细节上我踩过一个比较大的坑一开始把所有配置硬编码在代码里结果维护多个环境的配置简直要命。后面统一把所有配置外置包括模型API地址、工具超时、熔断阈值、prompt模板、路由规则全部放入配置中心容器启动时拉取。业务方调整prompt或者工具描述时只需要改配置不用重新构建镜像。镜像构建也做了两层拆分基础镜像只装Python运行时和常用依赖业务代码通过另一个阶段拷贝进去。这样业务代码更新时基础镜像层可以复用镜像构建速度大幅提升。整个服务无状态运行横向扩容只需要增加副本数配合负载均衡就能做到分钟级扩展。7. 仓库维护期间沉淀下来的配置经验7.1 工具描述的质量决定选型准确率工具描述这个点我想再单独强调一下。很多Agent项目跑不好不是模型不行而是工具描述写得不清晰。描述里至少要说清楚三件事这个工具是干什么的、什么场景下用、什么情况下不要用。比如订单查询工具我会写上“仅用于查询订单状态和金额不可用于修改订单、不可用于查询其他用户订单”。模型一旦遇到模糊场景就知道应该返回权限不足而不是硬调工具。随着工具数量增长这个经验越来越重要。工具从最开始的三五个涨到二十多个之后工具的误选率如果没有明确描述撑着会直线上升。我后面专门安排了一个人负责维护工具描述业务方提新工具时必须按格式提交少一项都不予上架。7.2 转人工标准该放手时就放手Agent做得再强也不能让它在没有把握的场景里硬答。这个仓库里制定了一套转人工的标准放进AgentLoop的判断逻辑里低置信度连续出现、工具结果与用户问题明显不匹配、触发安全白名单约束、连续两次追问仍未澄清意图、用户明确提出“转人工”这五种情况一律转人工。清醒地控制Agent的能力边界比追求“全自动”重要得多。很多项目最后死在“模型什么都要答”上出了事也没有兜底通道。行业级应用尤其要克制哪些业务允许Agent自主决策哪些必须人来确认这个边界需要在系统设计时就定清楚而不是上线后等问题暴露了再补。7.3 上线后的迭代节奏仓库上线初期我保持了比较稳健的迭代节奏每两周出一个版本每个版本只改一个核心模块。第一版优化工具协议第二版优化记忆压缩策略第三版调整循环控制参数第四版做部署和监控改进。这个节奏让我们每期都能清楚看到改动对指标的影响而不是一次性把一堆改动混在一起出了问题都不知道是谁引起的。整个仓库从立项到稳定运行大概花了三个月时间。回头总结这个项目最核心的技术决策都在架构初期就确定了工具协议标准化、记忆分层、循环控制、可观测性、容器化容量规划。中间踩过的那些坑也大多是因为最初能偷懒的地方没有坚持工程化标准。如果准备做类似的Agent项目建议先把这些基础打好再考虑加更花哨的功能。