1. 什么是父子Agent架构它不是新概念而是老问题的新解法“父子Agent架构”这个词最近在AI工程圈里频繁出现但很多人一听到就下意识觉得是某种高深的新型框架甚至误以为是某个大厂刚开源的黑科技。其实完全不是——它本质上是对一个存在了至少五年的老问题的系统性回应上下文污染Context Pollution。我从2019年开始做对话式AI系统最早在客服机器人项目里就踩过这个坑用户问“上个月账单是多少”系统正确调用了账单查询工具紧接着又问“那这个月呢”模型却开始胡编乱造因为它的记忆里混进了上一轮查询返回的原始JSON字段、数据库字段名、甚至调试日志里的SQL片段。这不是模型能力不足而是上下文管理失控。所谓“父子Agent架构”核心就一句话让每个子任务拥有独立、隔离、可销毁的上下文空间父Agent只负责调度、聚合与兜底不参与具体执行细节。它不是替代LangChain或LlamaIndex的框架而是一种设计范式——就像当年微服务之于单体架构它解决的是AI系统规模化后的“上下文耦合”问题。你不需要换掉现有LLM也不用重写全部prompt只需要在任务编排层加一层轻量级隔离机制。关键词“父子Agent架构”“上下文污染”“AI系统”“技术方案”全指向这个本质上下文生命周期管理。适合三类人正在用Agent做真实业务比如电商导购、金融投顾却频繁遇到幻觉率上升的工程师被“多轮对话崩坏”困扰的产品经理以及想真正理解Agent底层运行逻辑的初学者——因为只要你开始写超过3步的Agent流程就一定会撞上这个墙。我见过太多团队把问题归咎于模型不够强花几万块升级GPT-4-turbo结果上线后发现第三轮对话就开始漏信息。后来我们回溯日志发现90%的污染源来自两个地方一是工具调用返回的原始API响应带时间戳、trace_id、内部错误码二是前序步骤中用户无意间透露的隐私字段比如“我叫张伟身份证最后四位是1234”后续步骤里模型会擅自把“1234”当成通用数字去推理。父子架构不解决模型本身的问题但它像给每条数据流装上单向阀门——子Agent执行完它的上下文内存立即清空连缓存都不留。这听起来简单但落地时涉及序列化策略、状态快照时机、错误回滚边界等实操细节。接下来我会拆解它为什么必须这样设计而不是用更“优雅”的全局状态管理。2. 为什么必须用父子结构上下文污染的四种典型场景与不可绕过的代价2.1 上下文污染不是Bug是LLM固有行为模式的必然结果很多人以为上下文污染是代码写错了其实它是Transformer架构的物理特性决定的。LLM没有真正的“记忆”它所有的“记住”都依赖token位置编码。当你把上一轮的完整对话历史含工具返回的JSON、系统提示词、用户口语化表达直接拼接进新请求模型会无差别地对所有token分配注意力权重。实验数据显示在128K上下文窗口中当工具返回的原始响应占满20%长度时模型对后续用户问题的理解准确率下降37%我们用Banking77数据集做的AB测试。这不是幻觉是注意力被噪声稀释后的必然衰减。父子架构的第一层价值就是物理隔离噪声源。父Agent只传递结构化指令如{task:查账单,params:{month:2024-05}}子Agent执行时才加载自己的最小化prompt模板和工具schema。这相当于把“菜市场嘈杂声”和“厨师听指令”彻底分开——父Agent是点单员子Agent是后厨两者之间只用标准化菜单沟通绝不让顾客对着厨师大喊“我昨天吃的红烧肉太咸”。2.2 四种高频污染场景及父子架构的针对性解法污染类型典型表现传统方案缺陷父子架构解法实测效果工具响应污染API返回含trace_id、debug字段、HTTP头信息的原始JSON模型从中提取错误字段生成虚假结论手动清洗JSON增加维护成本且无法覆盖所有API格式子Agent加载时自动剥离非业务字段仅保留{amount:129.5,date:2024-05-01}等白名单键工具调用失败率下降62%跨轮次语义漂移用户问“推荐三款手机”模型返回列表再问“最便宜的是哪款”模型却开始对比参数而非价格依赖模型自身记忆长程依赖失效父Agent将第二问解析为新子任务{task:比价,items:[iPhone15,Mate60,S24]}子Agent无历史上下文跨轮次准确率从41%→89%敏感信息泄露用户说“我的工号是A12345”后续步骤中模型在生成报告时擅自加入该工号Prompt中加“不要提及工号”无效模型仍会复现子Agent执行报告生成时父Agent不传递任何用户原始输入仅提供脱敏后的结构化数据PII泄露事件归零状态残留干扰多步骤表单填写中用户修改第3步导致第1步数据被覆盖全局state对象易被意外修改每步子Agent独立维护本地state父Agent通过版本号合并变更表单提交成功率提升至99.2%提示很多团队尝试用“上下文压缩”替代父子架构比如用LLM summarize历史对话。实测发现在金融场景中压缩后丢失关键数字的概率高达28%我们抽样分析1000条交易对话。父子架构不压缩而是消灭污染源——这是根本性差异。2.3 不采用父子架构的真实代价不只是准确率下降2023年我们帮一家保险公司在售前咨询系统落地Agent初期用单Agent架构QPS达200时幻觉率突破15%。他们第一反应是加更多few-shot例子结果训练成本翻倍准确率只提升2个百分点。后来我们引入父子架构改动仅涉及任务分发器和子Agent初始化模块幻觉率降至3.7%且支持QPS扩展到800。但更关键的是运维成本变化调试时间单Agent日志需人工筛选10个嵌套层级的token流平均定位一个污染问题耗时47分钟父子架构下子Agent日志独立存储问题定位缩短至6分钟灰度发布风险更新某个工具调用逻辑时单Agent需全量回归测试父子架构下只需验证对应子Agent测试用例减少73%合规审计GDPR要求“数据最小化”单Agent日志包含全链路原始输入审计整改需重构日志系统父子架构天然满足子Agent日志仅含脱敏后的结构化输出。这些不是理论优势而是我们在三个不同行业客户现场踩坑后总结的硬指标。父子架构的“技术方案”属性正在于它把抽象的AI伦理要求如数据最小化转化为可落地的工程约束。3. 核心实现父子Agent的三层结构与关键参数设计3.1 架构全景图父Agent不是调度中心而是契约制定者父子Agent架构由三层组成每层职责严格分离父Agent层Orchestrator不调用任何工具不生成用户可见文本只做三件事① 解析用户原始输入为结构化任务树② 为每个子任务分配唯一ID与超时阈值③ 聚合子Agent返回结果并生成最终响应。它的prompt模板只有87个token核心是定义任务契约“你只能输出JSON字段必须为task_id、result、status禁止添加任何解释性文字”。子Agent层Executor每个子Agent实例绑定单一任务类型如query_bill、compare_price、generate_report加载专用prompt模板含领域知识约束和工具schema。执行完毕后立即销毁实例内存清零。关键设计在于上下文注入点只允许从父Agent传入的结构化参数进入禁止读取全局变量或缓存。通信层Contract Bridge不是消息队列而是轻量级序列化协议。我们用Protocol Buffers定义TaskRequest/TaskResponse二进制序列化后体积比JSON小63%且天然支持字段校验——若子Agent返回了父Agent未声明的字段通信层直接丢弃并触发告警。注意很多开源项目把父Agent做成“智能路由”让它根据意图选择子Agent。这是危险的设计父Agent必须是确定性的状态机。我们曾见过某团队让父Agent用LLM判断“用户是否在问价格”结果模型把“这个套餐贵吗”识别为“资费咨询”而非“比价”导致错误调用资费说明子Agent。正确做法是用正则规则引擎预分类准确率99.98%。3.2 子Agent初始化决定污染防控成败的五个参数子Agent启动时以下参数必须显式配置缺一不可context_window_size上下文窗口大小不是模型最大长度而是子Agent实际使用的token数。例如账单查询子Agent设为512强制截断prompt参数总长度。计算公式prompt_tokens json.dumps(params).length() * 1.3 context_window_size*1.3是tokenizer编码膨胀系数。我们实测发现超出窗口5%就会引发注意力偏移。allowed_fields白名单字段定义工具返回JSON中哪些键可被子Agent读取。例如银行账单API返回23个字段但子Agent只允许访问{amount,date,description}。其他字段在序列化时直接删除而非注释掉——避免模型学习到“被注释的字段也重要”。timeout_ms毫秒级超时必须精确到毫秒。父Agent设置子Agent超时为3000ms但子Agent内部工具调用超时设为2800ms预留200ms用于序列化和网络传输。若超时子Agent返回{status:timeout,result:null}父Agent据此触发降级逻辑如返回“系统繁忙请稍后再试”。memory_limit_mb内存限制Linux cgroups限制子Agent进程内存。设为128MB一旦超过立即OOM kill。这比软件层内存监控更可靠——防止LLM推理时因cache累积导致内存泄漏。log_level日志等级子Agent默认只记录ERROR和CRITICALDEBUG日志需动态开启。关键原则子Agent日志不包含任何用户原始输入只记录结构化参数和结果。例如用户输入“张伟身份证1234”日志只记{user_id:U_8a3f,task:verify_identity}。这些参数不是配置项而是契约条款。我们在部署时用Schema校验器强制检查缺失任一参数则子Agent拒绝启动。这看起来繁琐但避免了90%的线上污染事故。3.3 状态管理为什么子Agent必须“无状态”以及如何安全地传递必要状态父子架构最常被质疑的点是“完全无状态怎么处理多步骤流程”比如用户先查账单再导出PDF。答案是状态不保存在Agent内而保存在父Agent控制的外部存储中且严格遵循“一次写入多次读取”原则。具体实现步骤1父Agent收到“查账单”请求生成唯一session_id如sess_7f2a存入RedisTTL30分钟内容为{step1:{bill_data:{amount:129.5,date:2024-05-01}}}步骤2用户说“导出PDF”父Agent解析为新子任务从Redis读取sess_7f2a的step1数据构造子Agent参数{bill_data:{amount:129.5,date:2024-05-01}}不传递session_id步骤3子Agent执行PDF生成完成后父Agent更新Redis中sess_7f2a的step2字段。关键设计Redis key命名规则agent_state:{session_id}:{step_number}避免跨session污染每次读取后立即设置新TTL如再续10分钟防止用户长时间不操作导致状态过期父Agent在聚合结果时才把各步骤数据合并为最终响应子Agent全程不知晓其他步骤存在。我们曾测试过让子Agent自己存取Redis结果在高并发下出现状态覆盖——两个子Agent同时读取同一session各自修改后写回后写入者覆盖前写入者。父子架构的“无状态”不是偷懒而是用确定性换取可靠性。4. 实操落地从零搭建父子Agent系统的七步工作流4.1 第一步定义任务树——用DSL描述业务逻辑而非写代码父子架构的起点不是写Python而是设计任务DSLDomain Specific Language。我们用YAML定义任务树因为它可读性强且易于校验# tasks.yaml - id: bill_query description: 查询用户账单 input_schema: type: object properties: user_id: {type: string, pattern: ^U_[a-z0-9]{4}$} month: {type: string, pattern: ^\d{4}-\d{2}$} output_schema: type: object properties: amount: {type: number} date: {type: string, format: date} items: {type: array, items: {type: string}} executor: bill_agent_v2 timeout_ms: 3000 - id: pdf_export description: 导出账单PDF input_schema: type: object properties: bill_data: {type: object, required: [amount,date]} output_schema: type: object properties: file_url: {type: string, format: uri} executor: pdf_agent_v1 timeout_ms: 5000这个文件会被编译成父Agent的路由表。关键点input_schema和output_schema用JSON Schema校验确保子Agent接收/返回的数据符合契约executor字段指向子Agent镜像名如Docker Hub上的acme/bill-agent:v2实现版本隔离所有字段必须有pattern或format约束避免宽松schema导致污染渗透。我们用Python脚本自动校验tasks.yaml检查是否有循环依赖、schema是否可解析、timeout是否合理10s。这步耗时2小时但省去了后期90%的调试时间。4.2 第二步构建子Agent镜像——轻量化与确定性的平衡子Agent不是微服务而是“一次性的函数容器”。我们的Dockerfile模板如下FROM python:3.11-slim # 安装最小依赖 RUN pip install --no-cache-dir torch2.1.0cpu torchvision0.16.0cpu -f https://download.pytorch.org/whl/torch_stable.html \ pip install --no-cache-dir transformers4.35.0 sentence-transformers2.2.2 # 复制子Agent代码仅1个.py文件 COPY bill_agent.py /app/ WORKDIR /app # 设置资源限制 CMD [python, bill_agent.py, --context-window512, --allowed-fieldsamount,date,items]关键实践不安装LLM推理框架子Agent只做prompt组装和API调用LLM调用由父Agent统一走API网关如vLLM集群。这样避免每个子Agent重复加载模型内存节省83%固定依赖版本torch2.1.0cpu而非torch2.0防止pip自动升级引入不兼容变更启动参数化所有关键参数context_window、allowed_fields通过CMD传入而非硬编码便于灰度发布时动态调整。子Agent代码bill_agent.py只有132行核心逻辑是解析父Agent传入的JSON参数根据allowed_fields过滤工具返回数据组装prompt并调用LLM API提取结果并按output_schema校验输出标准化JSON。这种极简设计让子Agent启动时间800ms故障时重启成本极低。4.3 第三步父Agent调度器开发——状态机比LLM更可靠父Agent的核心是确定性状态机。我们用Python的transitions库实现状态图如下idle → parsing → routing → executing → aggregating → done ↓ ↓ error timeout关键代码片段class ParentAgent: def __init__(self): self.machine Machine(modelself, states[idle,parsing,routing,executing,aggregating,done,error], transitions[ [start, idle, parsing], [parse_success, parsing, routing], [route_success, routing, executing], [all_done, executing, aggregating], [aggregate_success, aggregating, done] ]) def on_enter_parsing(self, user_input): # 用正则规则引擎解析非LLM if re.search(r(账单|费用|多少钱), user_input): self.task_tree load_task_tree(bill_query) elif re.search(r(导出|PDF|打印), user_input): self.task_tree load_task_tree(pdf_export) else: self.trigger(parse_failure)为什么不用LLM做意图识别因为LLM的随机性会破坏状态机确定性。我们测试过相同输入“帮我查五月账单”LLM在100次调用中有7次识别为“资费咨询”导致路由错误。规则引擎准确率99.99%且可审计——每条规则都有业务负责人签字确认。4.4 第四步通信层实现——Protocol Buffers比JSON更安全我们定义task.protosyntax proto3; package agent; message TaskRequest { string task_id 1; string executor 2; bytes params 3; // 序列化后的JSON bytes int32 timeout_ms 4; } message TaskResponse { string task_id 1; enum Status { SUCCESS 0; TIMEOUT 1; ERROR 2; } Status status 2; bytes result 3; // 序列化后的JSON bytes }生成Python代码后通信逻辑# 父Agent发送 request TaskRequest( task_idt_abc123, executorbill_agent_v2, paramsjson.dumps({user_id:U_8a3f,month:2024-05}).encode(), timeout_ms3000 ) serialized request.SerializeToString() # 通过gRPC发送... # 子Agent接收 request TaskRequest() request.ParseFromString(serialized) params json.loads(request.params.decode()) # 执行任务... response TaskResponse( task_idrequest.task_id, statusTaskResponse.Status.SUCCESS, resultjson.dumps({amount:129.5,date:2024-05-01}).encode() )优势params和result字段是bytes天然防止JSON注入攻击Protocol Buffers序列化后体积小网络传输更快字段编号1,2,3保证向前兼容新增字段不影响旧版子Agent。我们放弃REST API因为HTTP header可能携带污染信息如X-Forwarded-For而gRPC的二进制协议更干净。4.5 第五步部署与灰度——用Kubernetes Job管理子Agent生命周期子Agent不是长期运行的服务而是Kubernetes Job。YAML模板apiVersion: batch/v1 kind: Job metadata: name: {{ .Values.task_id }} spec: backoffLimit: 0 # 不重试失败即终止 template: spec: restartPolicy: Never containers: - name: executor image: acme/{{ .Values.executor }}:{{ .Values.version }} args: [--context-window{{ .Values.context_window }}, --allowed-fields{{ .Values.allowed_fields }}] resources: limits: memory: 128Mi cpu: 500m env: - name: TASK_PARAMS valueFrom: configMapKeyRef: name: task-params key: {{ .Values.task_id }}关键设计backoffLimit: 0子Agent失败不重试父Agent负责重试逻辑restartPolicy: Never确保单次执行避免状态残留memory: 128Mi硬限制OOM时Job自动失败父Agent捕获异常参数通过ConfigMap注入而非环境变量避免敏感信息泄露。每次用户请求父Agent动态生成Job YAML并kubectl apply。Job完成时Kubernetes自动清理Pod内存彻底释放。我们监控Job成功率低于99.5%自动告警——这比监控API延迟更能反映污染问题。4.6 第六步日志与监控——聚焦“污染发生点”而非“系统指标”父子架构的日志体系有三个核心原则子Agent日志不包含原始输入只记录{task_id:t_abc123,params_hash:a1b2c3,result_hash:d4e5f6}父Agent日志记录全链路ID{trace_id:tr_7x9y,steps:[{task_id:t_abc123,status:success},{task_id:t_def456,status:timeout}]}污染检测日志单独输出当子Agent返回结果中出现未声明字段时触发POLLUTION_DETECTED日志含{task_id:t_abc123,unexpected_field:trace_id,value:xyz789}。监控看板只关注三个指标污染率count(POLLUTION_DETECTED) / count(TaskResponse)阈值0.1%告警子Agent内存峰值max(container_memory_usage_bytes{containerexecutor})持续120Mi触发扩容父Agent状态机卡顿histogram_quantile(0.95, rate(state_machine_duration_seconds_bucket[1h])) 2.0。我们放弃监控“LLM token使用量”因为那只是结果不是原因。污染率才是根因指标。4.7 第七步上线验证——用对抗测试暴露隐藏污染上线前必须做对抗测试而非常规功能测试。我们设计三类攻击用例噪声注入测试用户输入“账单查询【DEBUG:trace_idabc123,envprod】”验证子Agent是否过滤掉DEBUG字段跨域污染测试连续发送“查张伟的账单”→“查李娜的账单”→“张伟的账单最便宜吗”验证子Agent是否混淆用户身份边界溢出测试构造超长参数{user_id:U_ a*1000, month:2024-05}验证子Agent是否按context_window截断。测试工具用Python脚本自动生成1000个对抗样本自动化执行。只有全部通过才能上线。我们曾在一个项目中常规测试100%通过但对抗测试发现23%的污染率——根源是子Agent的JSON解析库未启用strict mode导致{amount:129.5\n\n// 注释}被错误解析。5. 常见问题与实战避坑指南那些文档里不会写的教训5.1 “子Agent启动太慢影响用户体验”——真相是你的初始化方式错了很多团队抱怨子Agent启动要2秒拖慢整体响应。我们排查发现90%的问题出在子Agent启动时加载了不必要的东西错误做法子Agent启动时加载整个LLM tokenizer即使只用它解析几个字段正确做法tokenizer只在需要时按需加载用importlib.util.spec_from_file_location动态导入更优解把tokenizer预热到共享内存子Agent启动时mmap映射启动时间从2100ms→140ms。另一个常见错误是子Agent启动时连接数据库。必须改为父Agent在路由阶段就建立DB连接池子Agent通过Unix socket复用连接。我们实测DB连接建立占启动时间的68%消除后整体P95延迟下降41%。5.2 “父子Agent增加了复杂度不如直接优化prompt”——当你的业务超过3个步骤时prompt优化必然失效有客户坚持用“超级prompt”解决所有问题给模型喂入2000字的指令。我们做过对比测试在保险理赔场景需查保单、核验材料、计算赔付超级prompt的准确率是63%而父子架构是89%。根本原因在于超级prompt的token占用固定但实际步骤数动态变化模型被迫在有限token内分配注意力父子架构中每个子Agent的prompt针对单一任务优化可长达800token且无干扰信息。更关键的是维护性超级prompt修改一处需回归测试全部场景父子架构中改查保单逻辑只测bill_agent_v2。我们统计过业务迭代速度提升3.2倍。5.3 “子Agent失败后父Agent怎么兜底”——设计降级链而非简单重试子Agent失败不能只重试要设计降级链。例如账单查询子Agent失败时Level 1调用备用API如从主库切到备库Level 2返回缓存数据带“数据可能非最新”提示Level 3转人工生成工单并短信通知用户。降级链必须在任务DSL中定义- id: bill_query fallback: - type: api_switch target: backup_billing_api - type: cache_read ttl: 3600 - type: human_handoff reason: BILLING_API_UNAVAILABLE父Agent按顺序执行fallback每层有独立超时。我们曾因没设计Level 3导致某次DB故障时用户看到“系统错误”NPS暴跌27分。加上人工转接后NPS回升至故障前水平。5.4 “如何评估父子架构是否真的解决了污染”——用污染指纹分析法不要只看准确率要建立污染指纹库。方法抓取1000个失败case的子Agent日志提取所有POLLUTION_DETECTED日志中的unexpected_field统计高频污染字段trace_id32%、debug_info28%、http_status15%、user_raw_input12%针对TOP3字段在子Agent中加专项过滤规则。我们发现87%的污染来自工具API的debug字段于是推动合作方在API网关层统一剥离从源头解决。污染指纹分析让我们把被动修复变为主动防御。5.5 “父子架构适合小团队吗”——用Serverless降低门槛小团队不必自建Kubernetes。我们用AWS Lambda实现轻量级父子架构父AgentLambda函数处理用户请求并触发子任务子AgentLambda函数执行单一任务执行完自动销毁通信通过SQS队列消息体为Protocol Buffers序列化数据状态用DynamoDB存储sessionTTL自动清理。成本对比K8s集群月均$2300Lambda方案月均$87。且Lambda天然满足“一次执行内存清零”比K8s Job更彻底。我们帮一个3人创业团队两周内上线QPS支撑到500。6. 性能与扩展性实测从单机到万级QPS的演进路径6.1 单机验证用Docker Compose跑通全流程本地开发用Docker Composedocker-compose.yml核心配置version: 3.8 services: parent-agent: build: ./parent ports: [8000:8000] depends_on: [redis, sqs] bill-agent: build: ./subagents/bill deploy: resources: limits: memory: 128M depends_on: [redis] redis: image: redis:7-alpine command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru关键技巧Redis内存限制256MB防止缓存撑爆宿主机bill-agent的deploy.resources.limits.memory强制128MB模拟生产环境用docker stats实时监控内存验证子Agent执行后内存是否回落。单机压测结果Locust工具并发100用户P95延迟840ms污染率0.02%并发500用户P95延迟1250ms污染率0.05%因Redis连接池耗尽优化增加Redis连接池大小污染率稳定在0.03%以下。6.2 水平扩展Kubernetes HPA如何精准扩缩子Agent子Agent是无状态Job不能用Deployment的HPA。我们用自定义指标指标源Prometheus抓取kube_job_status_succeeded{job_name~agent-.*}扩容条件avg(rate(kube_job_status_succeeded[5m])) 0.95成功率低于95%缩容条件avg(rate(kube_job_status_succeeded[15m])) 0.995成功率高于99.5%。为什么不用CPU/Memory因为子Agent是短时任务CPU使用率波动剧烈无法反映真实负载。成功率才是业务指标。实测QPS从200升到2000时子Agent Job数量从50个自动扩到420个P95延迟保持在1100ms±50ms。扩容过程无请求失败因为父Agent有重试队列。6.3 高并发瓶颈父Agent成为单点用分片路由破局当QPS超5000父Agent的gRPC server线程池成为瓶颈。解决方案分片路由。将用户ID哈希为0-63每个父Agent实例只处理对应分片用Consul做服务发现自动注册/注销分片分片数64单实例QPS上限80总容量5120。关键设计分片算法必须幂等。我们用crc32(user_id.encode()) % 64确保相同user_id永远路由到同一父Agent避免状态分裂。上线后QPS从4800提升至12000P95延迟从1420ms降至1080ms。分片后单个父Agent故障只影响1/64用户MTTR从47分钟降至3分钟。6.4 成本优化为什么子Agent不用GPU以及何时必须用子Agent99%的场景无需GPU它只做prompt组装、API调用、结果解析计算量极小GPU显存昂贵且子Agent启动时加载CUDA驱动耗时增加300ms我们用CPU推理batch_size1吞吐量达120 QPS/核。必须用GPU的唯一场景子Agent需执行图像处理如OCR识别账单截图。此时单独部署GPU子Agent集群父Agent识别到图片输入路由到GPU集群GPU子Agent执行完结果存OSS返回URL给父Agent。成本对比CPU子Agent $0.0012/次GPU子Agent $0.018/次。我们通过精准路由GPU调用占比0.3%整体成本可控。7. 未来演进父子架构不是终点而是AI系统工程化的起点父子Agent架构解决了上下文污染这个燃眉之急但它暴露了更深层的问题AI系统缺乏像传统软件那样的模块化契约。当前子Agent的output_schema只是JSON Schema但真正的契约应包含性能SLA如P951s、错误码语义如ERR_TIMEOUT表示可重试、数据合规声明如“不存储PII”。我们正在推动的演进方向契约即代码Contract-as-Code用OpenAPI 3.1定义子Agent接口自动生成客户端SDK、mock服务、测试用例污染感知网络Pollution-Aware Network在网络层插入eBPF探针实时检测HTTP/GRPC流量中的污染字段自动拦截子Agent市场Executor Marketplace企业内部共享经过认证的子Agent镜像带安全扫描报告和性能基线新人可直接复用acme/bill-agent:v2无需从零开发。这些不是空中楼阁。我们已在两个客户现场落地契约即代码用Swagger UI可视化所有子Agent接口产品经理可直接测试开发效率