[2026.9.30] AI实践2

🦯

至目前生产环境使用下的AI实践经验

摘自实习总结的Agent对研发影响思考

3.1 对Agent 赋能研发的思考：从人工 Steering 到 Agent 自闭环

从去年 Opus4.5 时期起，我的研发就从「亲手实现」过渡到了「定义目标、供给上下文、验收结果」：开始时给目标｜约束｜先验知识，中间观察COT与工具调用（OMP模型意图）、及时 Steer、来不及就OMP /tree CC /rewind Codex fork回退，最后核查代码 diff 与产物交互验证——其实还是human in the loop，只是从连续执行变成了离散介入。

今年这套方式又推进了一步，也可以说是退了一步——从loop里退下来。以前模型long horizon的水平还有限，反复人工验证太贵：无法廉价确认「结果对不对」，才必须盯着「过程在不在正轨」。而现在如果能把验证做进环境——静态校验让错误在提交前就被拦下（LSP Server｜Rust编译检查）、提交后能够根据运行回报日志获取hints（AI很方便做调试日志埋点）、通过自动化启动应用交互拿到真实环境反馈（浏览器自动化，computer use），使得非AI self proclaimed，符合人真实预期的「任务跑通」可以做成Agent判定的信号——由此过程有整体交给 Agent 闭环的可能：推理 → 验证 → 再推理 → 再验证，直到通过。人的介入退成环外的两件事：定义「什么算对」，以及搭出这套能自动判定对错的环境。

在实习里这种思路也有一些落地场景：

|---|---|---|---|---|

从这些实践可以看出，方向是一致的：把「验收」从人的监管转成Agent的自检

*研发方式佐证：opencli 自动化建角色权限*

CDP跟截图方式操作，“浏览器”应用都可以如此

*研发方式佐证：Agent 驱动 Agent 自动建任务（pty 交互）*

pty模拟终端，Agent可以发送操作指令（方向键上下）模拟人与Agent交互

3.2 进一步地-对开发者影响的思考：自闭环之上，判断力不可替代（for now）

3.1 讲的「Agent 自闭环」把「任务正确」做成Agent自检标准，Agent 能自己「推理→验证→再推理」最终达成goal。但这里面有个隐含假设：**只要通过验证，就是对的**，但实际工作中一些场景这个假设不成立，比如**多条路径都能通过验证，但它们并不等价**：

以数据源渲染为例，可以在链路上任意节点，Skill 层、引擎层、管控层任选去做适配——都能让任务跑通，但长期维护成本不同；验证能判断「对错」，但不能判断「优劣」。当方案空间中存在多条「正确」的路径时，Agent未必能独立正确抉择，回答如「哪条路更符合业务演进方向？哪条路长期维护成本更低？」的问题，这就是目前开发者的价值所在，提供一些人独有的判断力：

具体而言，可以按一些更具体的情形阐释这一点：

*对「度」的把握——对抗AI的防御型编程。* LLM（尤其gpt）在校验上经常层层加码，把能力白名单写死在CLI、Web、Skill，但如果这样做，每加一条哪怕已有逻辑的新通道要同时改三个仓的白名单、发三个应用的版本，给研发增加不必要的负担与风险；且LLM给出的代码也可能没有可拓展性，比如ES与Milvus同样支持JSON表达建表，可以归为一类，但LLM可能一个通道写一个逻辑，把分类做成枚举，哪怕主要逻辑一样，也可能因为多出的防御校验硬凑出多个函数。

*对「意图」的保真——防止降智曲解语义。* 在做数据源通道适配时，要求「最小改动、防止回归」，两个类要复用同一个方法，继承同一个接口，一种自然的解法是把公共方法提取到公共 Interface做默认实现，AI（5.6 sol medium）提议调整继承关系来「复用」—— 如果AI就按这个自主决策了，diff行数更少，但所有子类的方法派发路径都变了，回归面反而最大。「最小改动」的语义是最小回归风险，不是最少行数；模型（尤其风控降智时）读的可能只是字面，但人要看到的是意图。

*对「盲区」的警觉——语义正确性在全局理解中。* Multi-Sink 各分支共享本地文件的删除时机，避免文件被其他消费更快的提前删除，AI 提议用 CyclicBarrier 让分支「到齐」再删，但我们项目在Flink环境下，这个任务可以自然地通过checkpoint的回调来处理删除，从而复用框架各种能力，而不是自己造一个脱离环境的边界处理不完善的轮子。这里的关键在于是否知道框架已经提供了什么能力、新逻辑该往哪里融入：AI可能在局限的视角下展开工作，但人要有一种全局的视角，能看到在直观内容之外的东西。

由此让我感受到工程师价值的三层转变：

*从「写代码」到「定义验收」*：把「什么算对」写进Agent自检里，让其能自闭环

*从「定义验收」到「关键判断」*：用业务判断、架构品味、规范理解、价值权衡来引导 Agent 区分「优劣」

*从「关键判断」到「沉淀判断」*：把这些判断过程、依据沉淀成文档做分享，让团队后来者和未来的 Agent 都能复用这种判断力

显然LLM 时代，工程师的竞争力显然不是「手写能力」，也不仅在「定义验收的能力」，更需要「在多条正确路径中选出最优解的判断力」——这是 Agent 短期内（至少截止今年九月）无法自产的能力，也是目前人引导 Agent 的重要资本。

4.1 下一步：把价值转变为工作方式

在实习里只是初步体验，接下来要探索成熟的方法论：

*验收要求与判断前置*：将与AI过往会话里一来一回中落定的对「度的把控、意图理解、全局上下文、验收标准」变成Agent动手前就能看到的东西（灵感：OMP learn Agent探索历程后自行调用会话前记忆注入）——规则约定、自检清单、可检索的弯路案例、能自查自验的工具、乃至仓库与知识库的组织方式。通过正确的上下文带来正确的AI行为。

*沉淀按「能被捡走」的标准*：调研托管 OSS 凭证时，Agent 自己摸出了数据建模团队的 STS

方案参考复用——这就算一种沉淀带来的复利；将自己验证过的方法与过程记录沉到团队知识库，让判断力离开个人也能存在。

常用规则文件约束

一般常用记规则文件中的：

简称语义

交互语言

行为约束（测试与生产代码边界）

便于人工参与的（diff | markdown行号引用 | 终端行号引用）

上游同步方式（默认ff only）

单次特性实现与测试范围约束

测试版本行为

markdown约束

subagent行为

测试AK

临时记忆

常用流程

自用脱敏案例：

临时记忆、测试AK、常用流程等按业务需要加入，此处脱敏不展示

TODO：生产级SKILL设计

基本思路：逐阶段（类状态机）+ 自检清单（Agent） + 正向案例 + 表格列字段与解释 + json schema（由CLI强校验）+ 交互门禁 + 路由与宪法约束（SKILL.md，表格化 + ID编号，其他地方交叉引用）+ 渐进披露（路由）+ 写作路由 + doctor指引

迭代：实测 → 出现Agent行为越界 → skill补充相关约束 → 测试循环

可以让agent自行测试，通过pty + python自行交互读取

TODO：生产环境Agent设计

用量统计

OMP

已转移到单独的文章

模型选择

grok 4.6/4.7

便宜大碗，如果不触发风控，速度与质量均适中，往下用flash往上用glm kimi

glm 5.3

优秀的日用模型

glm 5.3 flash

没有官key的dsv4.1f可以smol首选

gpt 6 astra

截至9.30 - 仍是SOTA，~~没有短板（难以访问）~~

opus 5

专业的干活模型

opus 5.5

用得还不多，感觉很懒的模型，能干活但要多次催促

fable 5

idea沟通可以，以编码实现而言性价比不高

kimi k3

如果没有astra，写作适宜，次于gemini3.8flash

编码太慢了

gemini 3.8 flash

非常适合充当讲解的角色，在”让人能看懂的解释“方面遥遥领先，暂时无其他替代，API AISTUDIO ANTIGRAVITY渠道均可

deepseek v4

pro 0813/flash 0731+思维链插件→没必要，往上grok glm 往下 glm flash

qwen 3.8 flash

没有5.3 flash可以代餐

grok 4.3

搜索用，同生态位对比效果 > 4.2 multi-agent/gemini2.5flash(但更快），如果要更即时的就得走exa或parallel了，gemini2.5flash走的cloud渠道，现已不支持免费档（

deepseek v4.1 flash

快近200TPS

思维链过长，完全不能靠观察思维链引导方向

速度快，但思考太长，完成速度可能甚至是慢的

神秘渠道max thinking

cline渠道官key较多，算可用，但模型比较肆无忌惮，可能会有安全风险

神秘渠道降智严重，不建议代码任务，只适合omp的smol角色，担当scout（查代码）或会话命名任务

同渠道high thinking

识图太快了

需要加以限制，避免做出来一些奇事