北京
八年前，Meta就有万亿参数模型了——但模型大小从来不是决定AI能力的唯一变量。
最近，Google工程师Addy Osmani关于"代理缰绳工程"的帖子在技术圈流传。核心观点很直接：编码代理的表现，更多取决于包裹在模型外的整套系统（提示词、工具、上下文策略、沙箱、子代理、钩子、反馈循环），而非模型本身的升级。Viv Trivedy的数据佐证了这一点——同一模型，换一套缰绳，在Terminal Bench 2.0上的排名从第30跃升至第5。见过几次这种幅度后，很难再把"选哪个模型"当作最关键的决策。
但这篇文章想补充一个被忽视的褶皱：当代理的任务是修改云原生系统中的代码时，"反馈"这件事变得异常棘手。
缰绳的框架依然成立，反馈循环的核心地位也依然成立。困难在于——在分布式系统里，"反馈"到底意味着什么？代理要在循环内收到信号，需要什么样的基础设施？
缰绳的各个组件权重并不相等。提示词决定代理尝试什么；MCP、CLI等工具决定它能操作什么；技能（skills）指导它如何尝试变更、选用哪些工具；策略与沙箱划定行动边界。这些共同塑造了代理的能力与行为模式。但没有一个组件能告诉代理：这次尝试是否成功。这是反馈信号的专属职能。反馈闭环，才是把代理从"开环生成器"转化为能自我修正、独立完成工作的关键。
Addy等人讨论的场景（单一应用、本地可运行、浏览器即可验证）中，反馈基础设施相对直接。编译报错、测试失败、类型检查不通过——信号清晰、路径明确。但在分布式系统里，同样的信号变得难以捕获。
什么才算好的反馈？Addy的框架很实用：成功静默，失败喧哗。类型检查通过，代理听不到声音；检查失败，错误被注入循环，代理自我修正。测试、lint、任何确定性检查都遵循同一形状。生命周期钩子（pre-commit、post-edit、pre-PR）把"我告诉代理做X"和"系统强制执行X"区分开来。没有强制反馈，缰绳的其他组件只是建议。
Anthropic在长时缰绳上的工作把这一逻辑推得更远。他们的三代理架构（规划者、生成者、评估者）驱动Playwright会话，在运行中的应用里点击遍历，按标准打分。数小时的运行后，产出可用的全栈应用。这里真正承重的是评估者——它提供了关于"是否达成目标"的明确信号。
云原生的麻烦在于，信号的路径被拉长了。代理修改了一段服务代码，但服务运行在Kubernetes集群里，依赖数十个上下游服务，状态分散在多个数据库和消息队列中。"它工作了吗"这个问题，答案可能藏在指标系统的某个面板里，可能埋在日志流的某一行中，可能需要跨多个服务的追踪数据才能拼凑。本地开发环境里，代理跑完测试就能知道结果；生产环境的等价验证，却需要代理理解整个可观测性栈。
更隐蔽的问题是反馈的延迟。本地测试秒级返回，集成测试可能分钟级，而生产环境的真实行为验证——金丝雀分析、错误率趋势、业务指标变化——往往以小时或天为单位。代理的循环被设计为快速迭代，但云原生的反馈天然慢一拍。缰绳的工程挑战，于是变成了如何在异步、嘈杂、分布式的信号中，提炼出代理能用的即时反馈。
一些团队正在尝试解法：把可观测性查询封装成工具，让代理能主动"询问"系统状态；用策略引擎把SLO违规转化为代理可解析的信号；在预生产环境注入故障，缩短反馈周期。但这些都不是现成的缰绳组件，需要针对具体系统定制。
模型升级带来的收益是通用的，缰绳的收益是场景特定的。云原生系统的复杂性，把"场景特定"这个变量放大了。同样的模型，在本地代码库上表现优异，进入分布式环境后可能频繁误判——不是因为模型变差了，而是因为反馈信号在传输中失真了。
这或许解释了为什么云原生领域的编码代理落地较慢。不是模型不够强，而是缰绳的基础设施还没跟上。反馈循环的工程，比模型选择更需要深耕具体场景。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
