Agent 上线频繁出问题？根源是 Prompt 没做拆分，ArkAPI 落地方法论请收好

很多 Agent 项目最早都是靠一整段系统提示词快速跑通 Demo。从角色定位、工具权限、输出规范再到内容禁限规则全部先塞进一段长文本里Demo阶段确实足够便捷。可一旦推向生产环境安全管控策略、业务专属规则、工具访问权限、异常兜底逻辑、人工升级机制、各类合规约束会不断叠加扩充最终这一大段 Prompt 彻底演变成 Agent 难以维护的 “臃肿控制台”。Google Developers Blog 近期写到的modular prompt transpilation》恰好精准解决了这个痛点生产级 Agent 的 Prompt不能一直靠手写长文本维护。它需要像代码一样被拆分、构建、校验、评审和发布。长Prompt怎么失控不少团队只把问题归结为 Prompt 篇幅过长真正的症结其实是缺少可治理性Google原文里分析最精准的是这三个问题。第一个是变更影响边界模糊在几千字的系统提示里改一句 “优先输出修复方案”可能连锁影响工具调用、风险判定、对用户的回复口径、人工介入触发条件。普通代码修改还能借助调用链路和测试用例来锁定影响范围但 Prompt 改动很难提前预判全局副作用。复制迭代产生规则漂移客服、运维、财务、知识库等不同业务 Agent都会共用安全边界、用户隐私数据处理规范、工具调用约束这类通用规则。初期可以复制一份模板直接微调效率很高但经过几个月的长期迭代各个 Agent 的同类规则会慢慢出现细微差异最终线上不同实例的执行行为就会出现明显分叉。问题暴露严重滞后单纯的模板和字符串拼接可以让文本变整洁但在没有构建配套的校验机制时变量没传、引用路径写错、模块循环依赖、低频分支生成非法指令等问题往往要等到线上真实用户请求触发后才会暴露故障。所以 Prompt 管理不能止步于模板化生产系统必须配套确定性构建、静态检查和 CI 流程。Prompt Transpilation做什么modular prompt transpilation 的思路很直接开发者维护模块化 Prompt 源文件构建系统解析 include、变量、条件逻辑和宏最后生成一份完整、确定、可审计的系统提示。企业团队可以类比成这种结构include shared/safety.prompt.md include shared/tool_usage.prompt.md 你是运行在 {{ environment }} 环境中的 SRE triage agent。 allow_remediation true 时 可以建议修复步骤破坏性操作需要人工批准。 allow_remediation false 时 只能检查、总结和解释问题。 调查步骤 - 检查最近部署 - 查看延迟和错误率 - 检索重复失败模式构建参数传入 environmentproduction、allow_remediationtrue 后transpiler 生成最终交给模型的系统提示。这样做的价值很具体模块能复用变量能检查最终产物能 diff变更能进 CI发布前能 review。Prompt 从手工文本变成了构建产物。关键是提前报错模块化本身是不够的。仅仅把长 Prompt 拆分为多个小文件并没有从本质降低复杂度。生产级的 transpiler必须提前拦截这四类高频问题模块引入缺失模块被 include但对应文件路径不存在构建失败变量未定义模板里用到了 environment、region、allow_remediation参数构建时没有传入赋值构建失败循环依赖问题Prompt 模块可以看成一张有向图文件是节点include 是边。safety.md 引入 tool_usage.md后者又反向引入前者就会形成递归导入。产物版本漂移CI 从源文件重新生成最终 Prompt再和仓库里的 golden file 对比不一致就失败。这样可以避免源码、构建产物和线上指令层各跑一套。这里最有价值的是把原本线上运行才会爆发的故障提前到构建环节就完成拦截。Skill减少上下文负担Prompt transpilation 处理稳定控制面。ADK Skills 和 Agent Skills Specification 处理另一个问题Agent 的知识和能力怎么按需加载。Google 在 ADK Skills 里强调 progressive disclosure。Agent 启动时只看到 skill 的名称和描述任务需要时再加载完整 SKILL.md还需要资料时再读取 references/、scripts/ 或 assets/。一个 skill 通常是这样的目录SKILL.md scripts/ references/ assets/SKILL.md 里的 description 很关键。它是 Agent 判断“什么时候该用这个 skill”的入口。ADK SkillToolset 对应三步list_skills load_skill load_skill_resource也就是先看技能列表再加载技能说明最后按需读资源。Google 给过一个对比如果 Agent 有 10 个技能全部塞进系统提示可能每次带上约 10000 tokens渐进式加载时启动阶段可能只带约 1000 tokens 的技能元信息。省 token 只是表层。上下文越少、越相关Agent 越不容易把无关规则套到当前任务里。Agent可以提议不能直接改线上规则Google 还提到 skill factory 的思路Agent 解决新问题后可以起草新的技能模块。比如 SRE Agent 处理了一类新故障它可以总结步骤生成 SKILL.md补充引用资料甚至建议改顶层 Prompt 的 imports。但这类变更不能直接进运行时。更稳的流程是Agent 生成变更提议提交 PRtranspiler 做静态检查评估集跑回归人工 reviewer 看过通过后再合入和部署。Agent 可以帮助维护指令层但不能绕过交付流程。否则“自我改进”很容易变成线上规则失控。ADK 2.0补上执行流把 Google 这几篇资料放在一起看可以看到一个共同方向Prompt、Skill、Workflow 各管一段。ADK 2.0 讨论的是执行流。企业 Agent 容易陷入循环、绕过业务逻辑或者失败时没有清晰异常一个常见原因是团队让 LLM 承担了太多编排工作。如果流程本来就确定比如审批要先校验身份再查额度再生成记录最后通知用户就应该交给代码、工作流图和状态机。模型只处理需要语言理解、判断、归纳和生成的节点。ADK 2.0 的 graph-based workflow runtime就是把 Agents、Tools、Functions 放到 workflow graph 里。流程由图控制模型在合适的节点发挥作用。落到团队分工上可以这样看规则稳定的用代码。 路径确定的用 workflow。 知识复用的做 skill。 行为边界放进基础 Prompt。 Prompt 变更走构建、评估和发布流程。对企业Agent的启发生产级 Agent 至少有两层。应用层管 Prompt、Skill、Workflow、Eval。Prompt 定义边界Skill 沉淀可复用知识Workflow 控制确定性流程Eval 做回归验证。平台层管模型接入、密钥、调用日志、环境隔离、成本统计、多模型切换和稳定性。ArkAPI 平台对应的正是平台层能力统一 API、多模型接入、调用管理、企业级服务和成本可控。团队可以把底层模型接入和调用治理收敛到平台把精力放在 Prompt 模块、Skill 库、评估集和业务流程上。Agent 进生产后难点不在让它回答一次而在多团队、多场景、多版本、多模型环境下持续可靠地工作。Prompt 工程接下来要进入构建、校验、版本化和治理流程。参考资料Building scalable AI agents with modular prompt transpilationDeveloper’s Guide to Building ADK Agents with Skills- Agent Skills SpecificationBuilding ADK Agents with Skills and ToolsWhy we built ADK 2.0ADK 2.0 Docs