Prompt即协议：构建可编排、可验证的LLM基础设施层

1. 项目概述：当提示词不再只是“输入”，而成为系统协议

“Prompt to Protocol”这个标题乍看像一句技术口号，实则直指当前大模型落地最隐蔽也最致命的断层——我们花了九成精力调提示词、写few-shot样例、堆RAG检索逻辑，却把真正决定系统能否扛住真实流量、持续交付价值的底层骨架，当成“等模型跑通再补”的次要事项。我带团队做过17个面向金融、医疗、政务场景的LLM应用交付，其中12个在POC阶段惊艳四座，上线三个月后却因响应抖动、上下文错乱、多轮对话状态丢失、安全策略无法动态生效等问题被迫降级为“人工辅助工具”。问题从来不在模型本身，而在我们把prompt当作一次性输入，而非可编排、可验证、可治理的协议接口。这个项目要做的，就是把散落在Jupyter Notebook里的提示模板、藏在config.yaml里的温度参数、硬编码在API路由里的角色定义，全部升格为具备版本控制、契约校验、链路追踪和熔断能力的基础设施层。它不替换任何模型，但让所有模型调用都像HTTP请求一样可预期、可监控、可回滚。适合三类人深度参考：一是正在从单点Demo向产品化演进的算法工程师，二是需要对LLM服务做SLA承诺的SRE/平台工程师，三是负责AI系统合规审计与风险管控的技术负责人。核心关键词——Agent-Oriented Infrastructure、Production LLMs、Protocol Design、Prompt Engineering、System Architecture——不是并列关系，而是因果链条：只有把Prompt升维成Protocol，才能支撑真正的Agent-Oriented Infrastructure；而后者，是Production LLMs唯一能长期存活的土壤。

2. 整体架构设计：为什么必须放弃“API Wrapper”思维

2.1 传统LLM服务封装的三大幻觉

很多团队的第一反应是写个“LLM Service Wrapper”：封装OpenAI API，加个缓存，套个Rate Limit，再扔进K8s里就叫“生产就绪”。这种做法在内部演示时丝滑无比，上线后却暴露三个根本性幻觉：

第一，幻觉：Prompt是静态文本。实际业务中，一个客服对话Agent的prompt会随用户身份（VIP/普通）、当前会话阶段（首次咨询/投诉升级/售后跟进）、实时库存状态（缺货/预售/现货）动态组合。硬编码的prompt字符串无法承载这种条件分支，强行拼接会导致token爆炸、上下文截断、逻辑冲突。我见过某电商项目把57种商品类目+3级用户等级+4种促销状态穷举出600+个prompt变体，最终靠Python字典硬管理，每次新增类目都要全量回归测试。

第二，幻觉：模型输出是独立事件。真实Agent必须维持状态：用户说“上一条说的优惠券怎么领”，系统得知道“上一条”指哪次调用、上下文窗口是否已滑动、历史摘要是否被压缩失真。传统Wrapper把每次请求当全新会话处理，状态全靠前端传session_id，后端无校验、无快照、无恢复机制。某银行理财助手上线首周，32%的多轮对话在第三轮出现“忘记用户刚问过收益率”的故障，根因是Redis里session状态过期时间设为固定15分钟，而用户阅读条款平均耗时18分钟。

第三，幻觉：安全与合规是前置过滤器。把敏感词过滤、PII脱敏、内容审核全放在prompt输入前或output返回后，看似简单，实则埋下双重风险：输入过滤可能误杀合法query（如“苹果手机”被当水果拦截），输出过滤可能破坏语义连贯性（如把“建议您联系当地派出所”截成“建议您联系当地”）。更致命的是，当Agent需调用多个工具（查余额→生成报告→发邮件）时，每个环节的输入/输出都需独立合规校验，而Wrapper模式无法在工具链路中插入校验点。

提示：这三点不是优化项，而是架构分水岭。跨过去，你建的是Infrastructure；停在这边，你写的只是胶水代码。

2.2 Protocol Layer的核心设计哲学

我们摒弃Wrapper，构建三层Protocol Layer，其设计哲学可浓缩为一句话：让Prompt成为可执行的契约，而非待解释的文本。这要求协议本身具备四个原生能力：

• 可编译性（Compile-time Verifiability）：协议定义必须能在部署前验证语法合法性、变量绑定完整性、工具调用约束（如“查余额”工具仅允许在用户已认证状态下触发）。我们采用自研的Prompt Schema DSL，语法类似TypeScript Interface，但专为LLM交互建模。例如定义一个金融咨询协议：

  protocol FinancialAdvisor { // 输入契约：强制包含用户ID、认证状态、当前持仓快照 input: { userId: string @required; isAuthenticated: boolean @required; portfolioSnapshot: { totalValue: number; riskLevel: "low" | "medium" | "high"; }; }; // 输出契约：规定结构化字段与容错兜底 output: { recommendation: string @maxTokens(200); confidenceScore: number @range(0.0, 1.0); fallbackReason?: string; // 当模型无法生成recommendation时必填 }; // 工具契约：声明可调用工具及触发条件 tools: [ { name: "getMarketData"; condition: "portfolioSnapshot.riskLevel === 'high'"; requiredParams: ["symbol"]; } ]; }

  这段DSL在CI阶段即通过AST解析器校验：检查portfolioSnapshot.riskLevel是否在input中定义、getMarketData工具是否存在、condition表达式语法是否合法。未通过则阻断发布——这比运行时抛异常早了至少20分钟。

• 可追溯性（Traceable Execution）：每次协议执行生成唯一Execution ID，并自动注入到所有下游调用（模型API、工具API、日志系统）。更重要的是，协议层强制记录决策快照：包括原始输入、协议编译后的完整prompt（含所有变量展开值）、模型返回的原始response、结构化解析结果、工具调用链路。某次客户投诉“系统推荐了错误基金”，运维同事3分钟内通过Execution ID查到：协议正确触发了getMarketData，但该工具返回的美股指数数据延迟了47秒，导致推荐逻辑基于过期数据。没有快照，这个问题会被归因为“模型幻觉”，永远无法根治。

• 可治理性（Governable Lifecycle）：协议不是一次写完就封存。我们支持协议热更新：新版本协议发布后，旧版本仍可处理存量会话（保障状态连续性），新会话自动路由至新版。版本间差异通过Diff Engine可视化呈现，例如标红显示“新增requirement：input.portfolioSnapshot.lastUpdateTimestamp”，并自动触发关联测试用例。某保险项目升级协议时，Diff Engine发现新增的lastUpdateTimestamp字段未在所有上游数据源中提供，立即阻断发布，避免了线上数据空指针异常。

• 可组合性（Composable Orchestration）：单个协议只解决一个原子任务（如“生成理赔摘要”），复杂Agent由多个协议按DAG图编排。编排引擎不碰prompt细节，只关注协议间的输入/输出契约匹配。例如“理赔处理Agent”协议流：ValidateClaim → ExtractEvidence → CalculateCompensation → GenerateLetter。每个节点都是独立协议，可单独测试、灰度、降级。当CalculateCompensation因税率规则变更需紧急修复时，只需更新该协议，不影响其他环节——这正是微服务思想在LLM领域的精准复现。

2.3 与现有技术栈的协同定位

这个Protocol Layer不是要取代LangChain、LlamaIndex或自研Orchestrator，而是为它们提供契约底座。LangChain的Chain本质是代码逻辑编排，而Protocol定义的是数据契约；LlamaIndex专注检索增强，Protocol则规定“何时触发检索、检索结果如何注入prompt、注入后如何校验格式”。我们实际部署中，Protocol Layer作为Sidecar容器与LangChain Worker同Pod部署：Worker收到请求后，先调用Protocol Sidecar进行输入校验与prompt编译，再将编译后的prompt与工具列表传给LangChain执行。Sidecar返回的Execution ID被注入LangChain的Callback Handler，实现全链路追踪。这种解耦让LangChain专注逻辑，Protocol Layer专注契约——就像HTTP协议不关心浏览器渲染逻辑，只确保Request/Response格式可验证。

3. 核心模块实现：从DSL定义到生产就绪的落地细节

3.1 Prompt Schema DSL的编译器实现

DSL编译器是整个Protocol Layer的基石，其设计必须平衡表达力与可验证性。我们放弃通用模板引擎（如Jinja2），原因有三：一是Jinja2语法过于自由，无法静态分析变量依赖；二是缺乏类型约束，{{ user.age }}可能为空导致运行时错误；三是难以注入安全钩子（如自动PII脱敏）。因此，编译器采用两阶段设计：

第一阶段：AST解析与静态校验
使用ANTLR4构建语法解析器，将DSL文本转换为抽象语法树。校验规则嵌入AST遍历过程：

• 变量绑定检查：遍历所有{{ variable }}节点，确认其在input或tools声明中存在，且类型兼容（如{{ user.id }}要求user.id为string类型）；
• 工具调用约束检查：对tools[].condition中的表达式，构建符号表验证所有引用变量均已声明，且操作符符合类型规则（如riskLevel === 'high'中riskLevel必须是string枚举）；
• 安全策略注入点标记：识别所有@pii("name")、@sensitive("account_number")等装饰器，在AST中打上安全元数据标签。

第二阶段：Prompt模板生成与运行时沙箱
校验通过后，编译器生成两个产物：

• Compiled Prompt Template：一个JSON Schema定义的模板对象，包含basePrompt字符串和variableMappings映射表。例如：

  { "basePrompt": "你是一名{{ role }}，请基于以下信息回答：\n用户ID：{{ userId }}\n持仓风险等级：{{ portfolioSnapshot.riskLevel }}\n---\n问题：{{ input.question }}", "variableMappings": { "role": { "source": "input.role", "type": "string" }, "userId": { "source": "input.userId", "type": "string" }, "portfolioSnapshot.riskLevel": { "source": "input.portfolioSnapshot.riskLevel", "type": "enum" }, "input.question": { "source": "input.question", "type": "string" } } }

• Runtime Sandbox：一个轻量JavaScript沙箱环境（基于VM2库），用于执行condition表达式和安全装饰器逻辑。沙箱严格限制：禁止网络请求、禁止文件IO、禁止全局变量访问，仅开放Math、Date等安全API。所有变量注入前经类型强转（如riskLevel强制转为枚举值，非法值抛出ProtocolValidationError）。

实操心得：沙箱性能是关键瓶颈。我们实测VM2在Node.js 18环境下，单次condition执行平均耗时1.2ms。为降低延迟，对高频协议（如客服问候语）启用编译缓存：相同DSL文本的编译结果缓存30分钟，命中率92%，P99延迟压至3ms内。缓存失效策略采用LRU+时间双维度，避免内存泄漏。

3.2 执行引擎（Executor）的可靠性设计

Executor是Protocol Layer的执行中枢，负责接收请求、加载协议、编译prompt、调用模型、解析输出、记录快照。其可靠性设计聚焦三个痛点：

痛点一：模型调用不可控的超时与重试
OpenAI等API的timeout参数仅控制HTTP连接，不涵盖模型推理耗时。我们观察到，当temperature=0.9且max_tokens=1000时，3%的请求实际耗时超30秒（官方SLA为60秒）。Executor采用三级超时：

• Network Timeout：5秒，控制DNS解析、TCP握手、TLS协商；
• Model Timeout：15秒，从发送请求到收到第一个token，超时则中断流式响应；
• Total Timeout：25秒，从Executor接收请求到完成所有后处理（含解析、快照写入），超时则返回EXECUTION_TIMEOUT错误码，并触发告警。

重试策略非简单指数退避，而是语义感知重试：仅对503 Service Unavailable、429 Rate Limited等明确服务端错误重试；对400 Bad Request（如prompt超长）或500 Internal Error（模型崩溃）绝不重试，直接失败。重试次数上限为2次，且第二次重试前强制切换模型版本（如从gpt-4-turbo-2024-04-09切至gpt-4-turbo-2024-01-25），规避特定版本缺陷。

痛点二：结构化输出解析的鲁棒性
要求模型输出JSON是反模式，但业务又需要结构化数据。Executor采用渐进式解析策略：

1. 首先尝试用正则提取json\n(.*)\n代码块；
2. 失败则用LLM自身做self-refine：构造新prompt“请将以下文本严格格式化为JSON，字段名必须为recommendation, confidenceScore, fallbackReason，不要任何额外说明”，调用轻量模型（如Phi-3-mini）重试；
3. 再失败则启动Fallback Parser：基于协议定义的outputSchema，用规则引擎提取关键字段（如匹配“推荐：(.*)”提取recommendation，“置信度：(\d+)%”提取confidenceScore）。

某次线上事故中，gpt-4-turbo在高负载下返回纯文本“我觉得这个产品不错”，三级解析全部失败。Fallback Parser成功提取出recommendation: "这个产品不错"，confidenceScore设为默认0.5，fallbackReason: "模型未返回结构化输出"。虽非完美，但保障了下游服务不中断——这正是生产环境的底线思维。

痛点三：执行快照的存储一致性
快照需同时写入日志系统（Elasticsearch）和对象存储（S3），但分布式系统无法保证强一致。Executor采用本地事务日志+异步补偿：

• 请求开始时，Executor在本地磁盘写入WAL（Write-Ahead Log）文件，包含Execution ID、时间戳、输入摘要；
• 所有处理完成后，同步写入ES（用于实时查询），异步触发S3上传任务（含完整prompt、response、解析结果）；
• 单独部署Compensator服务，每分钟扫描WAL目录，对比ES中是否存在对应Execution ID的记录。若WAL存在而ES缺失，则重放快照；若ES存在而S3缺失，则重新触发上传。

该设计使快照丢失率从千分之三降至零，且WAL文件自动清理（保留24小时），磁盘占用可控。

3.3 Agent编排器（Orchestrator）的DAG调度实现

当单个Protocol无法满足需求时，Orchestrator将多个Protocol按DAG编排。其核心挑战在于：如何让不同协议的输入/输出自然衔接，而不陷入“胶水代码地狱”？我们的方案是契约驱动的自动绑定。

以“智能投顾Agent”为例，其DAG包含三个Protocol节点：

• ValidateUser：输入userId，输出{isValid: boolean, riskProfile: string}；
• GenerateStrategy：输入riskProfile，输出{assetAllocation: object, expectedReturn: number}；
• CreateReport：输入assetAllocation和expectedReturn，输出{pdfUrl: string}。

Orchestrator不硬编码字段映射，而是通过Schema Matching Algorithm自动推导：

1. 解析ValidateUser输出Schema，提取所有可导出字段（isValid,riskProfile）；
2. 解析GenerateStrategy输入Schema，查找字段名匹配（riskProfile）或类型兼容（string匹配string）的字段；
3. 若找到唯一匹配（riskProfile），则自动生成绑定：GenerateStrategy.input.riskProfile = ValidateUser.output.riskProfile；
4. 若存在多匹配（如GenerateStrategy同时需要riskProfile和investmentHorizon，而ValidateUser只输出前者），则报错要求人工指定。

该算法支持三种匹配模式：

• Exact Match：字段名与类型完全一致（最高优先级）；
• Type Coercion Match：如number→integer、string→enum（中优先级）；
• Semantic Match（实验性）：调用轻量Embedding模型计算字段名语义相似度（如risk_level与riskProfile相似度0.87），需人工确认（最低优先级）。

注意：Orchestrator绝不自动执行语义匹配，必须显式开启且需审批。某次测试中，ValidateUser.output.accountBalance被语义匹配到GenerateStrategy.input.investmentAmount，但前者是人民币单位，后者是美元，自动绑定将导致资产配置错误。此教训让我们将语义匹配设为手动开关，并强制要求单位字段（currency）必须Exact Match。

4. 生产环境部署与运维实践：那些文档里不会写的坑

4.1 K8s部署的资源配额陷阱

Protocol Layer作为Sidecar部署时，资源配额设置极易踩坑。我们初期按常规Java服务经验，为Executor容器分配2CPU/4Gi，结果上线后频繁OOMKilled。根因在于：V8引擎的内存管理与JVM完全不同，Node.js进程的RSS（Resident Set Size）包含大量V8堆外内存（如libuv线程池、SSL上下文），而K8s的memory.limit只限制cgroup内存，V8堆外内存不受控。

解决方案是双维度监控+弹性配额：

• 监控维度：除K8s原生container_memory_usage_bytes外，必须采集Node.js进程的process.memoryUsage().rss和v8.getHeapStatistics().total_heap_size。我们用Prometheus Node Exporter + custom metrics exporter实现；
• 配额维度：Executor容器memory.limit设为3Gi，但通过--max-old-space-size=2048参数强制V8堆内存上限为2GB，剩余1GB留给堆外内存。实测此配置下P99内存占用稳定在2.3Gi，OOMKilled归零。

踩过的坑：曾将--max-old-space-size设为3072（3GB），认为留足余量。结果V8堆外内存暴涨，RSS达4.1Gi，触发OOMKilled。教训是：V8堆外内存与堆内存呈正相关，堆越大，堆外开销越高。2GB是经过200+压力测试得出的黄金值。

4.2 协议版本灰度发布的实操流程

协议更新不能全量切换，必须灰度。我们采用流量特征+协议版本双路由：

• 第一层路由：流量特征（如userId % 100 < 5）将5%请求导向新协议；
• 第二层路由：协议版本（如protocolVersion: "v2.1"）在灰度流量中精确控制。

关键在于灰度效果的量化评估。我们定义三个核心指标：

• Success Rate：协议执行成功的比例（非HTTP 200，而是output契约校验通过）；
• Latency Shift：新协议P95延迟 vs 旧协议P95延迟，允许浮动±10%；
• Fallback Rate：触发Fallback Parser的比例，超过基线值2倍即告警。

灰度发布流程强制要求：

1. 新协议上线前，必须跑通所有关联测试用例，Success Rate ≥99.5%；
2. 灰度期间，每5分钟计算一次上述指标，任一指标异常则自动回滚；
3. 全量前，需完成72小时稳定性观察，且Fallback Rate连续24小时低于基线。

某次FinancialAdvisor协议升级，灰度期间Fallback Rate从0.1%飙升至1.2%，排查发现新协议中@pii("phone")装饰器在处理国际号码（+86 138****1234）时正则匹配失败。此问题在单元测试中未覆盖，灰度监控第一时间捕获，避免了全量故障。

4.3 安全合规的动态策略注入

合规不是静态配置，而是随监管政策动态调整。我们设计Policy Injection Framework，支持运行时注入策略：

• 策略类型：PII脱敏（如手机号掩码规则）、内容审核（如禁止提及具体竞品）、输出格式（如强制JSON schema）；
• 注入方式：通过K8s ConfigMap挂载策略文件，Executor监听ConfigMap变更事件，热加载策略；
• 执行时机：在Prompt编译后、模型调用前，以及Model Response返回后、解析前，各插入一次策略执行。

某次金融监管新规要求“所有投资建议必须标注‘历史业绩不预示未来表现’”，我们仅需更新ConfigMap：

policies: - type: "output_append" target: "FinancialAdvisor" content: "\n\n*注：历史业绩不预示未来表现。*"

5分钟内全集群生效，无需重启服务。策略执行日志统一接入SIEM系统，满足审计要求。

实操心得：策略注入必须有熔断机制。我们为每个策略配置errorThreshold（如连续5次执行失败），超限则自动禁用该策略并告警。曾因正则引擎bug导致PII脱敏策略无限循环，熔断机制在3秒内禁用策略，保障主流程不受影响。

5. 常见问题与排查技巧实录：来自237次线上故障的总结

5.1 “协议执行成功，但业务逻辑错误”类问题

这类问题最棘手，因为日志显示status: SUCCESS，但用户反馈“推荐了错误产品”。根源往往在协议契约与业务语义的错位。我们建立了一套标准化排查路径：

关键技巧：所有协议DSL必须附带// @business-semantic: "用户风险承受能力等级，取值：low/medium/high"注释，并在CI阶段用正则扫描注释完整性。此措施将语义错位类问题减少76%。

5.2 “执行延迟突增”类问题

延迟问题常被归咎于模型API，但Protocol Layer自身也是瓶颈。我们按延迟分布定位根因：

• P50延迟正常，P95/P99突增：大概率是沙箱执行condition表达式或安全装饰器时遇到极端输入。例如@pii("id_card")正则/^\d{17}[\dXx]$/在处理超长字符串时回溯爆炸。解决方案：为所有正则添加(?-i)标志禁用忽略大小写，并用re2引擎替代JavaScript RegExp。
• 全量延迟升高：检查V8堆内存。process.memoryUsage().heapUsed持续>1.8GB时，触发Full GC，造成200ms+停顿。解决方案：调整--max-old-space-size=2048并增加GC日志--trace-gc --trace-gc-verbose，分析GC频率。
• 延迟呈周期性波动（如每5分钟一次）：通常是Compensator服务扫描WAL目录导致I/O争抢。解决方案：将WAL目录挂载为tmpfs内存文件系统，或调整Compensator扫描间隔为随机值（如300±30s）。

5.3 “协议版本混乱”导致的状态不一致

多协议编排时，旧协议处理的会话状态可能被新协议读取，引发类型错误。例如v1.0协议中portfolioSnapshot无lastUpdateTimestamp字段，v2.0协议新增该字段并要求非空，当v2.0节点读取v1.0生成的会话状态时，lastUpdateTimestamp为undefined，触发契约校验失败。

我们采用状态迁移器（State Migrator）解决：

• 每个协议版本声明migratesFrom: ["v1.0"]；
• State Migrator监听协议版本变更，对存量会话状态执行迁移脚本（如if (!state.lastUpdateTimestamp) state.lastUpdateTimestamp = Date.now();）；
• 迁移脚本必须幂等，且在Executor启动时自动执行。

独家技巧：在协议DSL中加入// @migration: "v1.0 -> v2.0: add lastUpdateTimestamp with default now()"注释，CI阶段自动提取并生成迁移脚本模板，减少人工编写错误。

6. 性能压测与容量规划：用数据说话的扩容指南

6.1 协议层自身的性能基线

我们对Executor进行标准化压测（wrk工具，100并发，持续10分钟），基准环境：AWS m5.2xlarge（8vCPU/32Gi），Node.js 18.18，V8 heap 2GB。关键结果：

注意：TPS非线性下降。当并发从100增至200时，复杂协议TPS仅从75降至62（-17%），但P95延迟从480ms飙升至1.2s（+150%）。这表明Executor的瓶颈在V8事件循环，而非CPU。扩容优先级：先水平扩展（加Pod），再垂直扩展（加CPU）。

6.2 模型API的容量联动规划

Protocol Layer的吞吐量受制于下游模型API。我们建立容量联动模型：
Executor_TPS = min(Protocol_Capacity, Model_API_Capacity)
其中Model_API_Capacity = (Model_Rate_Limit / Avg_Response_Time)。

以gpt-4-turbo为例，Rate Limit为10,000 TPM（Tokens Per Minute），实测平均响应时间350ms，平均每次请求消耗850 tokens，则理论容量为：
10000 / 850 ≈ 11.76 RPS
而Executor在中等协议下可达180 TPS，远超模型API容量。因此，Executor的Pod数不应按自身TPS规划，而应按模型API的RPS反推：
Required_Pods = ceil(Model_RPS / Executor_RPS_per_Pod)
= ceil(11.76 / 180) = 1

但这是理想值。实际需考虑：

• 模型API的TPM是滚动窗口，瞬时burst可能超限；
• 不同协议token消耗差异大（简单协议300 tokens，复杂协议2000 tokens）；
• 多模型混用（如gpt-3.5-turbo用于简单任务，gpt-4-turbo用于复杂任务）。

因此，我们采用动态配额池：为每个模型API创建Token Bucket，Executor从桶中申请tokens，桶容量=模型TPM * 0.8（预留20% buffer）。当桶空时，Executor自动降级至备用模型或返回RATE_LIMIT_EXCEEDED。此设计使模型API超限率从12%降至0.3%。

6.3 成本优化的三个实战技巧

LLM生产环境成本高昂，Protocol Layer可显著优化：

技巧一：Prompt压缩率提升
通过DSL的@compress装饰器，自动移除prompt中冗余空格、注释、重复指令。实测某金融协议压缩后token减少22%，直接降低22%的模型计费。压缩逻辑：

• 移除/* ... */和// ...注释；
• 合并连续空白字符为单空格；
• 移除JSON Schema中@required字段的冗余描述（如"userId: string // 用户唯一标识"→"userId: string"）。

技巧二：缓存策略分级

• L1缓存（内存）：编译后的Prompt Template，TTL 30分钟；
• L2缓存（Redis）：相同输入参数的Execution结果，TTL 5分钟（适用于低频变化数据，如用户基本信息）；
• L3缓存（S3）：高频不变的协议输出（如“服务条款摘要”），TTL 24小时。
  某客服场景启用三级缓存后，整体模型调用减少37%，P95延迟下降41%。

技巧三：降级策略自动化
当模型API超时或错误率>5%时，Executor自动切换至轻量模型（如Phi-3-mini）执行相同协议。Phi-3-mini的token成本仅为gpt-4-turbo的1/20，虽质量略低，但保障了服务可用性。切换逻辑嵌入Executor的Retry Policy，无需业务代码修改。

7. 从项目到产品的演进：Protocol Layer的边界思考

这个项目做完，我们没止步于“内部工具”，而是将其产品化为Prompt Protocol Platform（PPP），已服务8家金融机构。但产品化过程中，我们不断反思Protocol Layer的合理边界——它不该试图解决所有问题，而应坚守三个原则：

第一，不替代模型选择。PPP不内置任何模型，只提供与OpenAI、Anthropic、Ollama、vLLM等的标准化适配器。某客户坚持用自研小模型，我们仅需开发一个50行代码的适配器，即可接入全部Protocol能力。强行捆绑模型只会让平台失去中立性。

第二，不侵入业务逻辑。PPP的Orchestrator只做DAG调度，绝不执行业务规则（如“风险等级high时股票占比不低于70%”）。这些规则必须写在GenerateStrategy协议的condition或工具调用逻辑中。否则，业务规则将散落在Orchestrator代码、协议DSL、工具代码三处，维护成本指数级上升。

第三，不承诺100%准确率。PPP保障的是契约履约率（Contract Fulfillment Rate），即协议定义的输入/输出/工具约束100%被执行，而非模型输出100%正确。准确率是模型与数据的问题，Protocol Layer只提供可验证、可追溯、可治理的框架。向客户承诺“99.9%准确率”是危险的，但承诺“99.99%契约履约率”是可测量、可改进的。

我在实际交付中最大的体会是：当团队开始用Protocol DSL写第一行代码时，讨论焦点就从“这个prompt怎么写”转向了“这个业务契约该怎么定义”。这种思维升维，比任何技术优化都珍贵。它让算法工程师、后端工程师、合规专家坐在同一张桌子前，用同一种语言（DSL）对话。最后再分享一个小技巧：在协议DSL中强制要求每个protocol块以// @owner: team-name注释开头，CI阶段扫描并自动创建Slack通知，@对应团队负责人。这看似微小，却让契约责任真正落地——毕竟，生产环境的稳定，从来不是靠技术单打独斗，而是靠清晰的责任边界。