本文是 DECO一个跑在生产上的数仓 Agent 引擎实践系列之一聚焦护栏层怎么用 Agent 框架的 Hook 切面把 LLM 处理长文本时的偷懒截断、略写、残缺、对生产环境的越权未确认发布、回刷以及上下文传递中的失忆改了表不查风险、产出了物不知汇报在代码层确定性兜底——prompt 管不住的框架来堵。DECO 作为腾讯一站式数据工程 Agent 智能协作平台以业务数仓知识库为基础致力于解决从需求到数据交付全过程主要聚焦于数据问询、开发、同步、分析、运维五大环节。希望帮助更多同学更轻松地获取数据、理解数据、应用数据助力数据平权。引子从两个真实案例说起案例一用户让 Agent 改一张核心表的 ETL——1200 多行的长 SQL。Agent 读完原文、开始输出写到一半偷懒了中间跳过一大段逻辑写了句省略然后若无其事地继续往下写。这份带省略号的脚本一旦提交上线下游几十张表当天的数据就会算错。案例二Agent 还在方案设计阶段、用户都没点头就径直调了发布工具把一张还在讨论的表结构推上了生产。这两个案例看似不相干根因却是同一个——不是模型能力不够而是它图省事或自作主张。具体有三种表现LLM 偷懒处理长脚本动辄上千行的 SQL / Python ETL时模型会截断、占位略写输出-- 其他字段...、跳步骤、把长 SQL 复印式重写到 token 耗尽最后剩一堆残缺、不可执行的脚本。越权操作发布、回刷、冻结/解冻、终止实例这些写生产或不可逆的动作模型无法区分操作的可逆性——它把发布和查询视为同一类完成任务的步骤可能不打招呼就直接调了。上下文失忆模型改完表不去分析下游风险、Python 产出图表不知告诉用户——「需要查的就不查」。模型被训练成用最短路径完成任务——额外一次 tool call 意味着多一步推理模型倾向于跳过看起来不必要的检查步骤。此处风险分析为事后下游影响评估非改表前拦截——事前拦截由 HITL Guard 负责。在 prompt 里多写几句 ⚠️ 禁止根本管不住。这不是 prompt engineering通过提示词约束模型行为能解决的问题——长 SQL 是物理上超出 token 预算危险操作是模型无法区分查询和发布的可逆性差异被动探测是模型追求最短完成路径的自然倾向。唯一的解法是在 Agent 框架层让偷懒和越权的路径代码级强制走不通让失忆的已知盲区确定性补齐。本文拆解这套机制——Hook 链Agent 框架的 Callback 切面 挂在它上面的读写两侧 offload长内容落盘、上下文仅留引用句柄 HITL 门禁 上下文联动闭环。一、背景数仓 Agent 的任务开发流程DECO 的数仓开发 Agent 帮用户把数据需求落成 US 平台上可运行的任务。先约定几个关键名词二、Hook 链在关键切面挂载护栏逻辑拦截这三类问题的切入口是 Agent 框架普遍提供的Hook或称 Callback机制框架在 Agent 运行的每个关键节点围绕模型调用和工具调用各有执行前 / 后暴露出切面。我们把拦截逻辑挂载到这些切面上——到点框架自动回调同一切面可挂多个、按序执行。一次会话沿这条流水线跑下来本文主要用到下面几个切面切面触发时机本文用它做什么Before ToolbeforeTool工具真正执行前可改入参、可直接拦截长脚本回写前从文件加载全文、危险操作确认HITL 门禁After ToolafterTool工具执行后、结果回给 LLM 前可改返回值长脚本拉取后把内容替换成引用句柄Before / After Model每次请求 LLM 前 / 后响应用户取消等Before / After Agent单个 Agent 运行前 / 后对话持久化等设计原则基础设施和推理逻辑解耦——Hook 切面上的逻辑独立运作模型的 ReAct 循环不用感知新增 / 删除一个 Hook主流程一行代码都不用改。本文逐层拆解三个最重要的应用长文本完整性护栏§三揪偷懒、危险操作确认 HITL§四封越权、上下文联动闭环§五补失忆。三、长文本完整性护栏让长脚本进出 LLM 都不出错3.1 长 SQL 在哪里被截断、略写数仓任务开发会遇到两类长脚本它们的偷懒形式不同修改场景从 US 平台拉来的存量长 SQL要在原脚本上局部改写后回写。风险集中在拉取—改写环节。新建场景LLM新生成的目标态长 SQL通过 US 平台保存/更新任务工具的scriptContent入参提交。风险集中在写回环节。无论哪种场景长脚本都要经过**拉取US 平台 → LLM和写回LLM → US 平台**两段每段都有各自高频的偷懒形式阶段偷懒形式现象后果拉取流式 token 自截断把长 SQL 塞进上下文后输出端重写时 token 预算耗尽文件截断成残缺 SQL回写即生产事故拉取view沙箱文件查看后create_file创建文件重写读长 SQL → 用创建文件工具把整段再吐一遍而非只改局部等于复印一遍输出 token 翻倍此路径下自截断概率接近 100%拉取占位 / 略写输出含(SQL略)、-- 其他字段...落盘脚本不可执行写回scriptContent入参自截断拼回写工具入参时长 SQL 在 JSON 串里被截断提交残缺脚本US 平台无校验一句话定位长产物的偷懒是结构性问题。解法是——把 LLM 必须接触的长内容降到最少、每次接触的窗口压到最小、所有写入路径都做成小步增量改 强制校验。根治方案让长 SQL 从 LLM 上下文里消失全文走文件通道——这就是读写两侧 offload 要解决的问题。3.2 框架层方案读写两侧 offload 引用句柄做法整体思路是——LLM 永远不直接接触脚本全文。两端都用 Hook 拦截 沙箱文件做中转站长内容全文留在沙箱LLM 上下文里只有一句引用句柄US 平台 ↔ 沙箱 ↔ LLM 三方各管一段LLM 只用str_replace小步改写最终通过文件路径入参把工作副本喂给回写工具。下文为可读性将盘路径统称/sandbox/实际代码中只读快照在/mnt/chat-offload/可编辑工作副本在/mnt/user-data/。拉取侧Offload HookafterToolHook 拦截到含scriptContent的响应后将全文写入沙箱只读快照响应中替换为引用句柄。句柄明确告诉 LLM “要改先copy_file把只读快照复制为可编辑工作副本再str_replace”offloaded to /sandbox/{taskName}.remote.etl (read-only snapshot, lengthN chars). To start editing, run copy_file(...) first, then str_replace.案例 · 同一个拉取长 SQL动作治理前后 LLM 看到的东西脱敏示意# 治理前约 3.8 万字符长 SQL 原样进上下文复印重写到一半 token 耗尽INSERT OVERWRITE TABLE dws_order_detail ...SELECT ... FROM dwd_a UNION ALLSELECT ... FROM dwd_b-- 其他字段... ← 占位略写输出在此截断下游 SQL 不完整# 治理后上下文里只剩一句引用句柄长 SQL 全文留在沙箱只读快照offloaded to /sandbox/order_detail.remote.etl (read-only snapshot, length37814 chars). To start editing, run copy_file(...) first, then str_replace.关键设计点响应形态适配单条 Map 和数组都要支持数组下每条 item 独立判定任一落盘失败仅该条降级避免一条出错让整批 SQL 全进上下文。失败降级落盘失败 → 该条返回原scriptContent让 LLM 至少拿到内容承担自截断风险不阻断主流程。写回侧Onload HookbeforeTool同模式延展表侧 Offload上面详细拆解的是任务脚本的长文本护栏链路。同一套 Hook 链上表侧也挂了完全对称的 Hook面向宽表 200–500 列场景心智模型与任务侧完全一致——读侧降级落盘失败透传、写侧阻断文件不存在抛异常。工具协议scriptContent与scriptFilePath互补参数回写工具同时声明两个参数scriptFilePath是纯框架契约scriptContent : 脚本内容。⚠️推荐改走scriptFilePath让框架Hook自动加载 避免长SQL拼入参时自截断仅沙箱不可用时才直接传。scriptFilePath :脚本的沙箱路径强烈推荐。框架OnloadHook会从沙箱读全文覆盖 scriptContent并在转发给本工具前剥离该字段下游实现侧不消费它。好处下游无感知协议不用改、框架可独立演化阈值/白名单/剥离规则升级都不影响下游、防御性日志兜底下游对scriptFilePath留log.warn——到达本工具时它本应已被剥离还在就是 Hook 失效信号。效果修改任务时模型不用再吐那几千行 SQL——它只输出脚本路径全文由框架在后台对齐。「长文本走文件路径修改任务的工具调用输出 token 直接降约 90%」的落地机制长 SQL 从此彻底从对话历史和 token 消耗里隐身。3.3 多重防线全景对应数仓四阶段这套护栏不是单点而是贯穿 Skills 编排篇那条流水线的多重防线每一阶段的防线正好对应 Skills 编排篇里那条数仓开发流水线设计→拆解→执行→验证四阶段的各个阶段——Hook 在框架层做物理兜底。图中隐含了两条关键分支未直接绘出以保持主线清晰Onload 阻断红线「⑤ → Onload Hook 加载工作副本」环节若scriptFilePath不在白名单路径、身份缺失、文件不存在或内容为空 → 抛异常阻断工具调用不进入 C1 后续。Offload 降级橙线「① Offload Hook 落只读快照」环节若 COS 落盘失败 → 该条原scriptContent透传给 LLM承担自截断风险不阻塞主流程。3.4长文本护栏效果小结把前面散落的数字汇成一张表均为脱敏汇总维度 / 指标治理前治理后offload 策略SQL 原样进出上下文全量落盘所有 scriptContent 自动换引用句柄修改任务工具调用输出 token每轮重传整段 SQL**直降约 90%**上下文仅留引用句柄SQL 复印自截断view → 重写路径下概率近 100%物理消除只走str_replace小步改读侧失败OffloadafterTool—降级透传可重试不污染生产写侧失败OnloadbeforeTool—阻断工具调用杜绝发布残缺脚本3.5 行业对比哪些是现成的哪些必须自研和 HITL 不同——HITL 是单点拦截决策各框架几乎都有一行配置或一个中间件搞定。长文本护栏是一个流水线问题拉取 → offload → 编辑 → onload → 写回没有哪个框架直接给一个开箱即用的完整闭环。但offload 引用句柄这个模式本身行业已有多种层级的实现注DECO 使用Java ADK其 Hook API 与 Python ADK 同构但接口名略有差异以下对比以 Python ADK 为例说明设计思路差异具体接口以 Java ADK 文档为准。工程读侧策略写侧策略自动化程度ADKArtifactServicesave_artifact/load_artifactAPI LoadArtifactsTool官方有context_offloading_with_artifact示例save→摘要→hook 注入→仅当前轮次可见❌ 需工具内手动调load_artifact再拼入参⚠️ 每个工具手动调用 API非 Hook 层自动拦截LangGraphDeepAgents内置 “Large Tool Result Offloading” 中间件工具结果 20k token 自动落盘消息中只留引用指针另有SummarizationMiddleware在 85% 容量时自动摘要压缩历史❌ 只做读侧✅ 全自动中间件层透明Anthropic Claude CodeRead默认 2000 行、offset/limit分页Edit强制str_replacePre-read requirement❌ 无 offload内容全留上下文两个关键结论ADK 和 LangGraph 都有内置的 offload 能力——如果 DECO 只需要读长 SQL 时把全文换成引用句柄用它俩的原生机制改造即可不是从零发明。但这两者的 offload 都只做到读侧工具结果 offload没有写侧 onload——因为大部分 Agent 场景不需要把长产物再原样发回外部 API。DECO 的数仓场景不同——有写长 SQL的保存工具长产物要原样回写 US 平台。这意味着必须两端对称 offload并且写回时需要额外加固加固项为什么框架原生覆盖不了写侧 onloadbeforeTool 加载全文覆盖入参ADK / LangGraph 的 offload 只做读侧写侧需自己实现从文件读回、覆盖scriptContent、剥离scriptFilePathscriptFilePath框架协议工具声明两个互补参数下层不感知Hook 层独立演化——ADK Artifacts 有 load API 但没有这种参数交换契约只读快照 / 工作副本分离防提前误改LLM 必须显式copy_file才能开始编辑——这是 DECO 踩坑后的设计不属于框架原生概念注释块按字段名识别 剥离US 平台默认注释块和 LLM 调度块用相同分隔线必须按字段名区分——纯业务逻辑框架不会内置列级 offload3 个对称 Hook宽表 200–500 列DDL 正文 columns 都要 offload——ADK / LangGraph 的 offload 不区分脚本和列的语义失败语义按代价差异化读侧降级、写侧阻断——框架的 offload 失败统一降级不会根据操作类型做差异化决策四、危险操作确认HITL用 beforeTool卡住不可逆操作4.1 通法写操作不可逆护栏要在框架层prompt 是软约束不是安全边界。任何做了就回不去的操作发布、回刷、冻结/解冻、终止都必须有一道代码级强制确认没拿到用户明确授权工具就是不能执行。这道闸必须在框架里。HITL 本质是一个特殊的beforeToolHook工具真正执行前判断是不是危险操作、用户授权了没没授权就阻断。它天然落在前面介绍的那套 Hook 体系里。4.2 配置驱动的危险工具守卫做法危险工具守卫挂在beforeTool切面上在 Hook 编排层统一调度。危险工具清单是配置出来的每个配一个授权标记requiredStatekey和确认对话框deco: dangerous-tools: -name:packCommit required-state:confirm_pack hint:需要用户先选择发布方式 confirmation: title:请确认发布方式 options: -{id:direct,label:直接发布免审批,value:direct} -{id:approval,label:提交审批,value:approval,hasInput:true,inputPlaceholder:请输入审批人RTX,inputType:text} -{id:draft,label:保存草稿,value:draft} -{id:edit_more,label:我再改改,value:edit_more}实际配置了多个危险工具每个对应不同的授权标记confirm_pack发布提交、confirm_deploy触发发布、confirm_upsert_datasource数据源变更、confirm_transfer_task_upsert同步任务变更。同一套 Guard 机制统一管控。守门流程——Agent 每次要调工具框架都会先过一道「门卫」无论 Agent 是自作主张还是被诱导只要没有人工确认这一步packCommit/deployCommit在框架层就物理走不通。§4.3 配图展开与用户握手的完整时序。4.3 一次完整的确认过程拦截 → 弹框 → 用户选择 → 放行用户点选项后前端经 REST API 把选择写进会话存储session.state再发起一次续跑请求复用引擎篇的续跑入口重新驱动同一会话——这一轮 LLM 重调该工具时 state 已就位守卫放行。确认框还支持带输入控件的选项hasInput/inputPlaceholder/inputType承载填审批人填回刷日期这类带参确认——不只是 yes/no。关键设计点必须框架层拦不能信 LLM。这套机制就是从框架层阻断 LLM 绕过 prompt 直接调packCommit/deployCommit确认动作只能由真实用户在前端触发。4.4 行业 HITL 全景与自研必要性DECO 的 HITL 是在 ADK 较早版本上自研的。如今 HITL 已是主流 Agent 框架的标配能力——开箱即用程度远超从零实现。先看行业全景框架开箱程度交互模式配置驱动暂停/恢复变更预览ADKToolConfirmation✅ 布尔确认一行配置高级确认requestConfirmation()可带结构化 payloadyes/no payload无原生多选 UI❌ 写在工具代码里✅ 框架原生❌LangGraphHITL Middleware✅ 声明式interruptOn配置approve / edit / reject / respond✅interruptOn映射✅ 框架原生 checkpointer❌Claude CodePreToolUse✅ shell 脚本 permissionDecisiondeny / allow / ask✅settings.jsonN/A用户侧脚本❌DECODangerousToolGuard❌ 需自研多选项 带输入控件 变更预览✅application.yaml自研事件 state 续跑✅COMMIT_PREVIEW其中 ADK 的ToolConfirmation1.0.0起内置当前最新1.4.0与 DECO 的深度对照维度DECODangerousToolGuard自研ToolConfirmationADK ≥1.0.0 原生触发方式beforeTool切面外部拦截工具内部调requestConfirmation()主动暂停危险清单配置驱动yaml工具无需改代码工具自身代码里声明暂停/恢复发事件 阻断靠 LLM 重试 state key 放行框架原生暂停 flow收到确认数据后恢复防循环用requiredStatekey 标记已授权框架自动清理中间事件 注入已确认 call前端交互自定义INTERACTION_BOX富交互框、多选项、带输入FunctionResponse回填布尔或 payload无原生多选 UI结论如果只需要调危险工具前问一声 yes/no直接用 ADK 原生ToolConfirmation即可——一行配置框架替你处理暂停/恢复和防循环这恰是自研最易出 bug 处。但 DECO 的场景要求更多发布前展示变更清单COMMIT_PREVIEW——用户不是盲选 yes/no而是先看改了什么确认框带参数选发布方式、填审批人、填回刷日期——不是 yes/no是结构化表单危险工具清单配置驱动——不同租户/环境危险工具不同不能写死在工具代码里和 SSE 流式协议一体——INTERACTION_BOX是CUSTOM事件的子类型确认框和文件事件、阶段事件走同一条管道。这四条ADK 原生和 LangGraph 的 HITL 都不直接覆盖——它们的 HITL 是工具级通用拦截DECO 要的是业务级集成确认。自研的必要性不在于框架没有 HITL而在于框架的 HITL 不够业务化。五、上下文联动闭环让 LLM 不再「需要查的就不查」5.1 第三类问题LLM 的「不作为健忘」前两类——偷懒长文本截断、略写和越权未确认发布、回刷——都是 LLM「做了不该做的」或「该做好的没做好」。还有第三类更隐蔽该做但没做的——改了 DDL字段重命名了——LLM不会主动去分析下游哪些表会受影响注此处风险分析为事后下游影响评估非改表前拦截——事前拦截由 HITL Guard 负责因为它「觉得」改表是自己的事、风险分析是额外的事Python 脚本跑完产出物生成了一张图表——LLM不会主动告诉用户图在哪除非用户追问表结构变更了字段元数据在上下文里已过时——LLM不会主动回查刷新继续用旧信息做决策。这不是模型能力不够而是「主动探测 额外一次 tool call 多耗 token」。模型天然追求以最少 token 完成任务不会主动给自己加检查步骤。在行业坐标系中这对应 ADK 官方 8 大 Hook 模式中的#2 动态状态管理——「在回调中读写 state使 Agent 行为可上下文感知在步骤间传递数据」。DECO 进一步把它拓展成了一个闭环范式Hook 采集事实 → 写 state → Attachment 注入下一轮 prompt。5.2 范式Hook 管「发生了什么」Attachment 管「下一轮告诉模型什么」这个范式的核心是把「副作用采集」和「上下文注入」解耦成两段各管各的这样做的好处是双重的采集是确定性的工具调用一定触发 HookHook 一定做完检查——不靠 LLM「记得去查」注入是时机正确的分析结果只在下一轮 prompt 里才需要不污染当前轮的上下文、不增加当前轮的 token 消耗。对比让 LLM 自己「记得去查」的方案方案可靠性token 开销LLM 偷懒风险prompt 里写「改表后记得分析风险」❌ 软约束无额外✅ 高——LLM 可能跳过单独发一轮「请分析风险」 依赖调度逻辑额外一轮✅ 中——LLM 可能敷衍Hook 采集 → state → Attachment 注入✅ 确定触发无额外结果复用❌ 零——不依赖 LLM 自觉5.3 案例一RiskAnalysisHook —— 改表后自动注入风险分析场景Agent 在 DDL 设计或执行阶段调upsertTable改了一张表的字段结构。LLM 的认知盲区它把「改表」当一次成功的工具调用完成了不会想到还要接着查改动影响了谁——下游几十张 ETL 可能因为一个字段重命名而直接报错。此处风险分析为事后下游影响评估非改表前拦截——事前拦截由 HITL Guard 负责。治理做法判定「改表」语义RiskAnalysisHook挂在afterTool上不从工具名硬判断——它看工具调用入参带了tableId参数的upsertTable就是改表新建表不带tableId。新建表语义直接跳过不触发风险分析。风险分析结果被 Attachment 注入后LLM 在下一轮回复中自然输出类似提示⚠️ 风险提示刚刚修改了 dws_order_detail 表的字段检测到下游影响- dws_channel_report (HIGH) — 依赖字段 order_amount- ads_daily_summary (MEDIUM) — 依赖字段 order_status建议检查这两张表的 ETL 是否需要同步调整。关键设计点判定条件精确带tableId才是改表避免新建表误触发风险分析累积写入 state一次会话多次改表风险结论累积下一轮一次性汇总注入。5.4 案例二PythonImageHook—— 自动发现并呈现生成产物场景Agent 调 Python 脚本做数据分析脚本产出了一张可视化图表但 LLM 的对话输出里没有图——用户必须自己去沙箱目录里翻。LLM 的认知盲区LLM 调 Python 工具时只知道脚本跑完了——它不知道脚本产出了什么新文件自然不会主动告诉用户「生成了 chart.png」。等用户问「图呢」LLM 要么已结束上下文要么需再调一次工具查文件列表。治理做法前端渲染Attachment 注入的不只是文本——预签名 URL 被写成结构化 JSON前端据此渲染内联图片。用户无需点按钮、不必翻沙箱目录图直接出现在对话流里。关键设计点前后文件快照对比beforeTool加文件快照、afterTool对比比让 LLM 用bash ls查文件可靠得多只关心图片仅关注.png/.jpg/.svg等图片格式不处理脚本和数据文件——避免 state 里塞无关文件列表累积写入一次 Python 执行可能产出多张图全部累积写入一次注入。5.5 为什么 prompt 管不住「自己查」§3.1 和 §4.1 已论证 prompt 管不住「长文本截断」物理约束和「未授权操作」模型输出不受限。对「主动探测」类问题前两条原因同样成立模型追求效率、prompt 是软约束、上下文干扰但还有一个独有原因信息不对称LLM 不知道 Python 脚本产出了什么文件——它是「瞎子」只能靠工具返回的 stdout/stderr 了解执行情况。如果返回里没提「生成了 chart.png」LLM 就不可能知道。这不是忘了查而是根本不知道有东西该查。确定性兜底解法只有一个不让 LLM「决定要不要查」而是框架在工具执行后强制采集、结果自动注入下一轮 prompt。这正是 Hook → state → Attachment 闭环做的事。5.6 行业对比谁在解决「上下文断裂」「跨轮次状态传递」不是 DECO 独有问题各框架都有解法但切入角度不同框架/工具DECO 的差异ADKArtifactServiceDECO 不依赖 artifacts——采集 → state → Attachment 是事件驱动 自动注入而非 LLM 主动 loadLangGraphcheckpointerDECO state 更轻量专用于「事实采集 → 上下文注入」不承载流程控制Claude CodeSessionStart / UserPromptSubmitDECO 在工具调用后、下一轮 LLM 调用前注入时效性更强CrewAITaskMemoryDECO 单 Agent 内多轮不涉及跨 Agent 协调DECO 这套机制的特殊之处它不是「存储 → 读取」的被动模式而是「事件 → 采集 → 注入」的主动流水线。Hook 不是等着 LLM 来查 state而是主动把结论 push 进下一轮 prompt——这意味着即使 LLM 完全不知道 state 里有风险分析结果Attachment 也会让它「看到」。一句话Hook → state → Attachment 闭环把「LLM 需要主动查」的操作降维为「框架主动 push」——LLM 不再是「需要查的就不查」而是「不管想不想查都会被喂到嘴边」。六、Hook 全景上面还挂着十余个横切逻辑三、四两节纵深拆解了两个深度案例——长文本读写两侧 offload 和 HITL 门禁。但同一套 Hook 链beforeModel/afterModel/beforeTool/afterTool/onRunEvent等切面上DECO 实际挂了十余个 Hook覆盖可观测、前端实时刷新、上下文联动、业务事件、沙箱环境等横切关注点。这一节从纵深拉回横展展现 Hook 体系的完整生态。它们都遵循同一条原则不改业务循环、不动工具实现把横切逻辑挂在切面上。分类Hook挂载点职责长文本护栏TaskScriptOffloadService/TaskScriptOnloadServiceafterTool / beforeToolETL 脚本读写两侧全量 offload治偷懒TableColumnsOffloadService/DdlColumnsOnloadServiceafterTool / beforeTool宽表 columns 读写两侧 offload几百列不经过 LLM tokenDdlBodyOffloadServiceafterToolDDL 正文无条件落盘 表元数据自动拼接注释块头危险操作护栏DangerousToolGuardbeforeTool危险工具拦截 HITL 确认工具返回处理LineageResponseOffloadServiceafterTool血缘原始响应 slimGraph 写 chat-offload/lineage/ToolResponseTruncatorafterTool超大返回智能裁剪超阈值触发Rerank 重排优先保留与当前问题最相关片段截断前写 COS、需要时回捞ToolResponseFormatterafterTool工具返回结构化格式化可观测 持久化ToolCallLogHookbefore/afterTool异步记录工具入参/出参/耗时/成功率toolNamethreadId配对LoggingHook多点Agent 执行链路日志ConversationPersistenceHookbeforeAgent / before·afterTool / onRunEvent落库 USER/MODEL/TOOL超长工具返回截断后入库前端实时刷新 业务事件SqlExecuteHookbeforeToolexecute_sql前先存盘并推FILE_TREE_CHANGEDCopyFileHookafterToolcopy_file后按 version 判定 CREATED/UPDATED 推文件树事件ReleaseItemCollectorHookafterTool收集发布条目推TASK_PLAN_CREATED/TASK_PLAN_UPDATEDocumentSaveHook阶段完成把阶段产物文档从 state 落盘剥离 markdown 代码块Hook→Attachment 联动RiskAnalysisHookafterTool改表时算单表变更风险写 state 供下轮 Attachment 注入PythonImageHookbefore/afterTool检测 Python 新产出图片生成预签名 URL 供 Attachment 注入沙箱环境EnvVarCaptureHookafterTool从bash export提取环境变量写入.sandbox_env重启后由init.sh恢复6.1 行业参照ADK 总结的 8 种 Hook 模式 Claude Code 参照看完 DECO 钩子体系的全貌再回看这套机制的行业坐标系。ADK 官方总结了8 种 Hook 设计模式这也是行业主流 Agent 框架普遍采用的分类模式说明DECO 对应防护栏与策略执行before_xxx 拦截违规直接返回预设响应✅ HITL 门禁4.2动态状态管理回调中读写 state 做跨步骤传递✅ offload 元数据写 state日志与监控关键点埋结构化日志✅ ToolCallLogHook缓存before_xxx 查缓存命中直返✅ 反向模式查文件缓存回填请求/响应修改修改 LlmRequest 或工具入参/出参✅ offload/onload 核心机制条件跳过步骤返非空结果阻止后续执行✅ Guard 返Maybe.just()短路认证与摘要控制工具级 auth、跳过 LLM 摘要—工件处理save/load artifact✅ COS 落盘 read-only snapshot结语这一篇讲的都是横切护栏不改业务循环、不动工具实现全靠挂在 Hook 切面上的护栏逻辑把prompt 管不住的三类问题在框架层确定性地兜住——长文本偷懒读写两侧 offload 引用句柄 强制str_replace 失败语义非对称让复印长 SQL提交残缺脚本物理上不可能。越权操作配置驱动的beforeTool守卫 富交互确认框让不可逆动作必须经真实用户授权。上下文失忆Hook 采集 → state → Attachment 注入闭环让「需要查的」自动 push 到 LLM 眼前不靠它自觉。它们服务于 Skills 编排篇那条数仓流水线的每个阶段也和引擎篇的扩展点共用同一套 Hook 机制。一句话总结就是prompt 定意图Skill 定规矩框架 Hook 定边界——能用确定性兜底的别交给模型。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
