为什么在金融机构用AI coding这么难

策划/编辑/研究：杨明月

最近 AI 编程圈有个说法很火：Vibe Coding——让 AI 帮你写代码，你只需要review一下对不对。听起来很美好，但在金融机构，这不太行得通。

对金融机构来说，监管合规、数据安全、系统稳定性，任何一条红线都不能碰。现有国内可以调用的多数AI 不知道你的合规边界在哪里，即使知道，也很难提供可以审计的流程。

所以，在国内金融机构做Agent工程化的核心命题是：设计让 Agent 在约束下正确产出代码的工程环境。

这也是最近很火的”线束工程”（Harness Engineering）的原理——给 AI 套上缰绳，让它在正确的跑道上奔跑。

01从泄漏的Claude code的六层架构聊起

要聊Harness Engineering，我们可以先看下典型案例Claude Code，的设计。前段时间的泄漏，让极客们纷纷开始抄作业并且迭代它的架构——粗地来看，Claude code可以拆解为六个层次：

🔍关键洞察是，如果在做线束工程时，只强化其中一层，系统就会失衡。

比如，你给了 AI 很强的执行能力，但没有验证层，它可能会自信满满地改坏生产环境。你给了丰富的工具，但上下文管理没做好，AI 会”失忆”，忘记之前的约束条件。

Agent 的核心循环应该是：收集上下文 → 采取行动 → 验证结果 → 完成或回退。四个环节缺一不可。

02上下文工程：

被低估的核心能力

很多人以为 Agent 的能力取决于模型有多强，其实更取决于上下文管理。

Claude Code 的上下文分层设计值得借鉴：

一个常见陷阱是，默认的上下文压缩算法会”智能”地丢掉一些内容。问题是，它可能丢掉关键的架构决策或安全约束。

解决方案是 Compact Instructions——你来控制压缩保留什么，不交给算法猜。

03三层控制体系

长话短说，在金融机构部署 一些日常的Agent，需要三层控制体系：

1. Skills：给 AI 一套工作方法

Skill 不是 Prompt 模板，而是标准化的操作流程。三种典型类型：

设计原则：每个启用的 Skill 都在”偷”上下文——占用 AI 的注意力。高频操作保持自动，低频操作手动触发，极低频的干脆移除。

2. Hooks：确定性控制层

有些事不能交给 AI 临场发挥，必须收回到确定性流程中。比如典型 Hook 点：

Hooks 的本质是：把关键节点的控制权从 AI 手中收回，交给确定的规则。

3. Subagents：隔离是核心价值

复杂任务应该交给子代理（Subagent）执行，主线程只拿摘要，保持上下文干净。

比如Claude Code 内置了三个子代理：

显式约束：给子代理设置工具白名单、模型选择、文件隔离，确保它不会越界。

04Agent 重塑金融机构团队

可以预见的是，编程 Agent 不只是让个人写代码更快，它正在重新定义金融机构团队的角色边界，特别是产品/IT团队。大多数人可能都要从”实现”转向”评审”——

谁都能出原型，但架构合理吗？安全吗？可维护吗？

在这场角色重塑中，核心考量是：

所以使用编程 Agent 对于金融民工来说，是必选项，不是加分项。不会用 Agent 的工程师/金融产品经理，就像不会用 IDE 的程序员。

05金融机构的特殊考量

相比互联网公司，金融机构部署 Agent 有额外的约束：

合规要求

06写在最后

Agent 工程化不是让 AI 取代工程师/产品经理，而是让大家从重复性工作中解放出来，专注于更有价值的架构设计和风险评估、价值实现。

“五个月一百万行零手写”的奇迹，背后是严密的工程体系在支撑。没有线束工程，AI 就是脱缰的野马；有了线束工程，AI 才是可靠的伙伴。

对于金融机构来说，这不仅是技术升级，更是组织能力的重构。谁先建立 Agent 工程化能力，谁就能在合规与效率之间找到最佳平衡点。

本文基于 日前我们给一家机构做的Agent 工程化培训方案延展而成，适用于金融机构在合规与安全约束下系统性搭建 Agent 工程能力。合作请进一步扫描二维码进一步沟通。