Page 1 - Showing 8 of 8 posts
View all posts by years →
- 拆一个能上生产的 Agent 运行时：依赖方向、循环与压缩
一个上得了生产的 Agent 运行时把代码切成调模型、跑循环、做业务几层。值得抄的不是它暴露了多少 API，而是循环靠什么停、压缩切在哪、对话存成什么形状这三处取舍。
16 min read - 横向验收任何一个 AI 产品：一张八层检查表
判断一个 Agent 能不能上线，不该看它演示得多聪明。把产品拆成任务、上下文、能力、编排、执行、验证、状态、信任八层逐项问过去，任一层答不上来，就是那个洞。
16 min read - 让 Agent 给自己打分，评测集就开始变成作弊集
自进化闭环一旦转起来，分数的含义就变了：题变窄、判据泄漏、模型给自己答案打高分，都能让曲线向上而能力不动。这篇写怎么给闭环装一根模型碰不到的尺子，也写闸门不装时分数往哪走。
16 min read - 先画依赖图，再写评测：你的指标会互相污染
三个指标同时掉，往往只是一个根因被记了三次。评测体系的顺序错了：先把执行依赖图画出来，再规定每个指标在什么条件下可评，才轮到 Judge 和门禁。
15 min read - 自治等级不是模型说了算，是能不能撤销说了算
给 Agent 多少自由度，判断依据不是模型看起来多聪明，而是动作的确信程度和撤销代价。L2 自治不是配置项，是幂等键、撤销窗口、补偿接口和审计工程出来的。
15 min read - 可验证性就是能力边界
生码只占研发链路 20% 到 30%，口径是需求到上线里写代码这段的耗时占比，继续优化它的边际收益已经很低。Agent 能走多远，取决于你能给它多少真实反馈——构建、测试、部署、日志、监控，缺一样它就只能靠训练分布猜。
16 min read - 给上下文定预算：Multi-Agent 的钱到底花在哪
多 Agent 拆分不天然省钱——并行意味着多份常驻上下文和初始化开销。真正把账单顶上去的是三类东西：常驻上下文、重复打包的历史，以及每次工具调用要付的四份固定开销。
16 min read - 代码不是真相：给 Agent 补上仓库里没有的几层
Agent 读得懂每个函数，却判断不了这次改动会影响谁。缺的不是代码注释，而是业务语义、隐式约定、运行时事实和历史决策——它们不在仓库里，也不该被塞进一个大而全的知识库。
14 min read