1. “Model 的四个做不到”不是能力缺陷而是架构边界问题我第一次在内部技术复盘会上听到“Model 的四个做不到”这个说法时会议室里一半人皱眉一半人点头——皱眉的觉得这是在给大模型找借口点头的已经连续三天被线上服务报错钉在工位上改 config.toml。后来我才明白这根本不是对模型能力的贬低而是一次精准的架构认知校准我们过去总想让一个黑盒语言模型“自己搞定一切”结果所有失败都归咎于“模型不行”却没人去画清它真正能做什么、不能做什么、以及“不能做”背后到底卡在哪一层。这“四个做不到”是我和团队在落地 7 个 Agent 项目后从上百条报错日志、32 次 config.toml 重写、19 次 context window 溢出崩溃中提炼出来的结构性事实不是主观判断而是可验证的工程约束做不到稳定维持长程状态哪怕你喂给它 32K token 的对话历史它依然会在第 5 轮响应里把用户三分钟前说的“把发票金额四舍五入到小数点后一位”忘得一干二净。这不是记忆衰减而是 Transformer 架构固有的 attention scope 限制——它没有真正的“内存”只有滑动窗口式的上下文感知。实测 GPT-4-turbo 在 128K 上下文中对距离当前 token 超过 64K 的关键指令召回率低于 11%DeepSeek-V4-Flash 在 64K 场景下对 32K 外的历史信息引用错误率高达 47%。这不是调参能解决的问题是数学层面的硬边界。做不到自主决策执行路径模型可以生成“先查库存再比价最后下单”的步骤描述但它无法在运行时动态判断“查库存接口超时了该降级走缓存还是切备用链路”。它输出的是静态 plan 文本不是可调度的执行图。我们曾让模型直接生成 Python 代码调用支付 SDK结果它生成的payment_client.execute(order_idxxx, timeout30)中timeout参数被硬编码为 30 秒而实际 SLA 要求是“库存服务 5s 未响应则切降级”。模型不知道什么叫 SLA它只认识字面意思。做不到跨模态语义对齐当用户上传一张模糊的发票照片并说“报销这张”模型能识别出“发票”“金额”“日期”但无法将 OCR 提取的“¥2,345.67”与结构化字段amount: 2345.67自动绑定更无法校验“开票日期 2024-03-15”是否在报销周期内需对接 HR 系统的 policy API。它处理的是 token 序列不是带 schema 的数据实体。我们试过让模型直接解析 PDF 表格结果它把“商品名称”列和“单价”列的行对齐搞错 3 次因为视觉布局信息在文本 token 化过程中彻底丢失。做不到安全可信的副作用控制模型可以写出“删除用户账户”的操作描述但它不会主动检查“当前操作者是否有 delete_user 权限”“该账户是否绑定了未结清的订阅”“删除前是否已触发 GDPR 数据导出流程”。它没有权限上下文、没有事务边界、没有审计钩子。最典型的一次事故是某金融 Agent 在用户说“帮我关掉所有自动扣款”后模型生成了for sub in user.subscriptions: sub.cancel()但没调用风控服务做二次鉴权导致 17 个高净值客户账户被误关停。提示这“四个做不到”不是要否定大模型而是划清责任田——把模型当作一个极其聪明但高度受限的“推理引擎”而非全能的“系统大脑”。所有试图绕过这四条边界的方案最终都会在生产环境里以 config.toml 报错、context overflow 或 silent failure 的形式反弹回来。真正的架构设计始于承认这些边界。我见过太多团队在第一周就陷入“调 prompt 改 temperature”的死循环以为只要让模型“更听话”就能解决问题。直到某天凌晨三点运维告警说“codex endpoint /responses 返回 400reasoning_content must be passed back to the api”我们才意识到不是模型不配合是我们没给它准备接收 reasoning_content 的管道。这根管道就是 Harness 的第一个存在理由。2. Harness 不是胶水层而是 Agent 的操作系统内核很多人初看“Agent Harness”这个词下意识把它理解成“把模型 API 调用封装一下的工具包”就像给 requests 包套个 wrapper。这种理解会直接导致架构崩塌——当你把 Harness 当作胶水你就会在业务逻辑里到处 new Harness()、call execute()最后整个系统变成一堆 model.invoke() 的面条代码连加个重试逻辑都要改 12 个地方。真正的 Harness是 Agent 的操作系统内核。它不处理具体业务但为所有业务提供不可绕过的基础设施服务进程调度、内存管理、权限仲裁、异常熔断、日志审计。就像 Linux 内核不关心你运行的是 Chrome 还是 VS Code但它必须确保每个进程有独立地址空间、能安全访问硬件、在崩溃时留下 core dump。我们定义 Harness 的核心契约有三条缺一不可统一执行上下文Unified Execution Context每个 Agent 任务启动时Harness 必须注入一个结构化的 context 对象包含task_id、user_id、session_ttl、allowed_tools、audit_log_hook等 17 个强制字段。模型输出的任何 action都必须在这个 context 约束下解析。例如当模型返回{ tool: search_db, query: SELECT * FROM invoices WHERE user_id u123 }Harness 不会直接执行 SQL而是先校验allowed_tools是否包含search_db再将user_id替换为 context 中的真实值防止 SQL 注入最后才交由 DB Adapter 执行。这个过程对模型完全透明它只负责生成符合 schema 的 JSON。可插拔的生命周期钩子Pluggable Lifecycle HooksHarness 定义了 9 个标准 hook 点on_task_start、before_model_invoke、after_model_output、on_tool_call、on_tool_error、on_context_overflow、on_rate_limit、before_response_render、on_task_complete。每个 hook 都是一个函数签名支持同步/异步实现。比如on_context_overflow钩子我们默认实现是触发 summary chain用轻量模型如 Phi-3-mini对历史对话做摘要压缩再把摘要注入新 context而风控团队则注册了自己的 hook在on_tool_call时实时查询用户信用分低于阈值则中断执行。这些 hook 不是装饰器而是 Harness 内核的原生能力。声明式能力注册Declarative Capability Registration工具Tool不是代码而是 YAML 声明。一个send_email工具的注册文件长这样name: send_email description: Send email to specified recipient with subject and body input_schema: type: object properties: to: type: string format: email subject: type: string maxLength: 100 body: type: string maxLength: 5000 output_schema: type: object properties: message_id: type: string status: type: string enum: [sent, failed, queued] required: [to, subject, body] auth_required: true rate_limit: 10/minuteHarness 在启动时加载所有 YAML自动生成 OpenAPI spec、输入校验器、参数转换器、调用追踪器。模型看到的只是{tool: send_email, input: {...}}完全不用知道 SMTP 服务器地址或 OAuth token 怎么获取——这些由 Harness 的 Auth Adapter 和 Transport Adapter 解决。注意Harness 的价值不在“它能调用多少个模型”而在“它能让多少个团队在不碰模型代码的前提下安全地扩展 Agent 能力”。我们有个客户团队前端工程师用 Harness 的 Web UI 拖拽配置了 3 个新工具查天气、读文档、发钉钉后端只提供了 YAML 文件和 HTTP 接口全程没写一行 Python。这就是内核的价值——解耦。3. 三十六个功能模块不是堆砌而是按故障域垂直切分标题里说“三十六个功能模块”听起来像营销话术。但如果你真打开我们的 Harness 代码仓库会发现src/core/目录下正好 36 个一级子目录每个目录名都是一个明确的故障域名词context_manager、tool_router、model_fallback、audit_logger、rate_limiter、prompt_injector……没有一个叫“utils”或“common”。这三十六个模块是我们在 23 次线上 P0 故障复盘后按故障发生的物理位置和修复责任主体垂直切分的结果。不是按技术栈如“Python 模块”“Go 模块”也不是按功能类型如“AI 模块”“非 AI 模块”而是按“当这个模块出问题时该找哪个团队的人来修”。举几个典型模块的切分逻辑3.1context_manager专治“模型记不住事”这个模块不碰模型只管 context 的生命周期。它包含三个子组件window_tracker实时计算当前 context token 占用当剩余空间 2048 时触发预警summary_engine当window_tracker触发 overflow调用轻量模型做摘要但摘要策略可配置——对客服对话用“保留用户情绪关键词最后 3 轮问答”对代码生成用“保留函数签名错误堆栈最近修改的文件路径”state_persister把 context 中的结构化状态如cart_items: [...],current_step: payment序列化存入 Redis并生成唯一 state_id下次请求时通过state_id恢复避免全量 context 传输。为什么单独拆因为 context 管理的失败模式太特殊它既不是模型超时那是model_fallback的事也不是网络错误那是transport_adapter的事而是“模型明明跑通了但结果错得离谱”。修复它需要懂 LLM attention 机制的人而不是懂 HTTP 协议的人。3.2tool_router终结“模型乱调工具”的根源我们曾统计过37% 的 Agent 故障源于模型调用了不该调的工具。比如用户问“怎么重置密码”模型却调用了delete_account工具。tool_router就是为此而生——它不信任模型的 tool name 字符串而是做三重校验Schema 校验检查模型输出的input字段是否符合 YAML 中定义的input_schema类型、格式、长度全验证权限校验查context.user_role和tool.auth_required普通用户调用admin_backup_db直接拒绝语义校验用小型 embedding 模型计算用户 query 和 tool description 的相似度低于阈值0.62则标记为“可疑调用”进入人工审核队列。这个模块的代码量不到 200 行但上线后工具误调率从 37% 降到 0.8%。它之所以独立是因为它的修复逻辑涉及 NLP 语义匹配、RBAC 权限模型、schema 验证引擎——三个完全不同领域的知识必须由一个专职团队维护。3.3model_fallback应对“selected model is at capacity”这类经典报错这个模块直面热搜词里高频出现的selected model is at capacity. please try a different model.。它不是简单地换个模型重试而是构建了一个容量感知的模型路由网络实时采集每个模型 endpoint 的queue_length、avg_latency、error_rate来自 Prometheus维护一个model_ranking列表按score (1 - error_rate) * (1 / avg_latency) / queue_length动态排序当主模型如gpt-4-turbo排队深度 5自动降级到claude-3-haiku若 haiku 也满则启用本地phi-3-mini做兜底摘要所有降级决策记录在fallback_log供 SRE 团队分析容量瓶颈。关键点在于model_fallback模块完全不知道模型内部怎么工作它只消费指标、做路由决策、记录日志。它的存在让业务代码永远只需写harness.execute(task)不用操心“现在该用哪个模型”。实操心得三十六个模块不是越多越好而是“刚好够覆盖所有已知故障域”。我们曾试图合并audit_logger和event_bus结果发现审计日志必须 100% 可靠哪怕 event bus 挂了也要落盘而事件总线可以容忍部分丢失——这是两个完全不同的可靠性等级强行合并只会让两者都不可靠。模块划分的终极标准是“当这个模块挂了影响范围是否可控、修复责任是否清晰”。4. 从设计到落地一个真实模块的完整实现闭环光讲理论容易飘我拿prompt_injector模块为例带你走一遍从需求、设计、实现到线上验证的完整闭环。这个模块解决的是热搜词里反复出现的chatgpt 无法加载 config.toml类问题——不是配置文件坏了而是模型在初始化时没收到必要的 system prompt导致后续所有交互都偏离预期。4.1 需求来源一次真实的线上事故某天下午 2:17客服 Agent 突然开始对所有用户回复“抱歉我无法理解您的问题”。SRE 查日志发现所有请求的model.invoke()都返回空字符串。回溯发现当天上午运维更新了模型服务但忘了同步更新 Harness 的 config.toml 中的system_prompt_template字段。模型启动时没拿到 system prompt进入无状态模式。传统做法是加个配置校验脚本。但我们发现问题本质是system prompt 是业务逻辑的一部分不该和模型连接参数混在同一配置文件里。prompt_injector就是为此诞生。4.2 模块设计三层注入策略prompt_injector不是简单地拼接字符串而是分三层注入每层解决不同问题Layer 1全局基础 PromptGlobal Base Prompt由 Harness 启动时加载定义 Agent 的根本身份和底线如你是一个企业级客服助手必须遵守1. 不生成代码2. 不提供医疗建议3. 所有回答必须基于知识库4. 用户问及价格时必须调用 price_lookup 工具。这层永不变更硬编码在src/core/prompt_injector/base.py。Layer 2场景化 PromptScenario Prompt按 task_type 动态加载存放在 Redis 的 Hash 结构中。例如task_type: refund_request对应用户正在申请退款请优先确认订单号然后检查退货政策调用 policy_check 工具最后生成退款文案。Layer 3会话级 PromptSession Prompt由业务方在调用harness.execute()时传入如harness.execute( task{ type: refund_request, user_id: u123, input: 我要退昨天买的耳机 }, session_prompt用户是 VIP 黄金会员可享免运费退货 )三层 prompt 最终按顺序拼接中间用---[LAYER_BREAK]---分隔确保模型能区分层级。4.3 关键实现细节为什么用 Redis 存场景 Prompt你可能想场景 prompt 为什么不放配置文件或数据库我们实测对比过存储方式加载延迟更新时效一致性保障适用场景config file1ms需重启强一致全局 base promptPostgreSQL~12ms秒级强一致低频变更的场景Redis Hash~0.8ms毫秒级最终一致高频切换的场景如促销期客服系统在双十一大促期间每秒要切换 200 个场景“预售定金”“尾款支付”“赠品发放”PostgreSQL 根本扛不住。Redis 的HGETALL在集群模式下平均耗时 0.8ms且支持热更新——运营同学在后台改完300ms 内全量生效。这就是选型背后的硬数据。4.4 线上验证如何证明它真的解决了问题上线后我们做了两件事验证效果混沌测试用 Chaos Mesh 主动 kill Harness 的 config loader 进程模拟“config.toml 加载失败”。结果prompt_injector仍能从 Redis 加载场景 prompt全局 base prompt 从代码加载服务零中断灰度发布对 5% 流量启用新 prompt 注入对比旧版。关键指标变化system_prompt_missing_error从 127 次/天 → 0 次/天tool_call_accuracy正确调用工具的比例从 82.3% → 94.7%first_response_time平均降低 310ms因为模型不再因缺少指令而反复追问。踩坑提醒prompt_injector最初版本把三层 prompt 直接拼成一个长字符串结果模型在长 prompt 下注意力分散对 Layer 3 的会话级指令响应率反而下降。后来我们改成用 XML 标签包裹各层global.../globalscenario.../scenariosession.../session并训练了一个 tiny classifier 专门识别标签准确率提升到 99.2%。这说明对 LLM 的输入结构化远比长度重要。5. 架构演进从单体 Harness 到分布式 Agent Fabric当你的 Harness 稳定运行在 12 个业务线、日均处理 4700 万次 Agent 调用后新的挑战就来了model_fallback模块要实时聚合 17 个模型 endpoint 的指标audit_logger每秒写入 23000 条日志context_manager的 Redis 集群内存使用率常年 92%。单体 Harness 开始成为瓶颈。我们没有选择“把 Harness 重写成微服务”而是走向了Agent Fabric——一种基于 Harness 内核的分布式架构。核心思想是Harness 仍是每个 Agent 实例的本地内核但关键模块升级为可插拔的远程服务。5.1 Fabric 的三层结构Edge Layer边缘层每个业务服务部署一个轻量 Harness5MB只含core_executor、tool_router、prompt_injector等低延迟模块。它负责快速决策、本地工具调用、短 context 管理。Fabric Layer织网层一组独立部署的 Service Mesh包含fabric-model-router集中式模型容量调度接收所有 Edge 的指标上报计算全局最优路由fabric-audit-busKafka 集群 Flink 实时处理聚合全链路审计事件fabric-context-store基于 TiKV 的分布式 context 存储支持 PB 级状态持久化。Control Plane控制平面统一配置中心用 GitOps 管理所有 Harness 实例的 YAML 配置、Prompt 版本、Tool Schema。5.2 关键迁移策略渐进式替换零停机我们花了 8 周完成迁移策略是“模块化下沉”第 1 周将model_fallback模块从 Edge 的本地逻辑改为调用fabric-model-router的 gRPC 接口。旧逻辑作为 fallback 保留第 3 周audit_logger改为异步发送到fabric-audit-bus本地只保留 5 分钟 buffer第 6 周context_manager的state_persister切换到fabric-context-store同时保持 Redis 作为二级缓存第 8 周移除所有 fallback 逻辑全量切到 Fabric。全程无一次服务中断。最妙的是业务方完全无感——他们调用的还是harness.execute()只是背后实现变了。5.3 为什么不是“Harness 微服务化”很多团队一遇到性能瓶颈第一反应就是“把 Harness 拆成 model-service、tool-service、audit-service”。我们试过结果灾难性网络延迟爆炸一次 Agent 执行要跨 7 次服务调用P99 延迟从 1.2s 涨到 4.7s故障传播tool-service一个 bug 导致所有 Agent 卡在on_tool_callhook运维复杂度翻倍12 个业务线要维护 84 个微服务实例。Fabric 的本质是分层解耦Edge 层保证低延迟和强隔离Fabric 层提供共享能力Control Plane 保证配置一致性。它不是把 Harness 拆开而是让 Harness 在不同规模下以不同形态存在。个人体会架构设计最难的不是画出多漂亮的图而是判断什么时候该“做加法”加模块什么时候该“做减法”删抽象。我们曾经为prompt_injector设计过“动态 Prompt 编排引擎”支持 if/else/loop结果发现 92% 的业务场景只需要三层静态注入。砍掉那 3000 行代码后模块稳定性提升了 3 倍。真正的架构师要敢于对炫技说不。