这一时期最清晰的信号是在约束下产品化：当编码代理的工作有状态、测试和廉价工具访问时，它们就有用；当平台无法吸收法律、审查或维护成本时，它们就有风险。Flathub、MCP 和 MLSys 提供了最强的证据。
团队编码代理正被当作带有状态、归属和验证记录的任务系统来看待。Charlie 的文章主张，Slack 线程、GitHub 评论、Linear issue、定时唤醒或审查请求都应变成持久任务，这类任务可以创建子任务、跟踪分支和 pull request、保留测试输出，并处理后续问题。文章声称小模型能带来成本收益，但没有提供受控基准。
两篇构建者报告说明了这种任务形态为何重要。Bearhug 的创始人声称，一名非程序员在 21 天内管理了 7 个编码代理，花了约 5,000 美元，为一个高管人才市场产出了超过 75,000 行生产代码。另一篇 YIMBY 公共数据文章描述了 3 个本地住房数据项目，都是用 Claude Code 在几个小时内完成的。这些都是生产环境轶事。它们展示了速度和规模，但质量、维护成本和可复现性都基本没有被衡量。
Model Context Protocol（MCP）现在被按 token 使用、延迟和失败模式来评估，而不只是看集成范围。Quandri 在 Claude Code 设置中测了 4 个 MCP server，发现任何调用前，工具定义就占用了 10.5% 的上下文窗口。仅 Linear 就加载了 42 个工具定义和大约 12,807 个 token，而该工作流只需要查一个 issue。
提出的替代方案是直接访问命令行界面或应用程序编程接口，再配上按需加载的短 Skills，告诉模型如何调用每个工具。在文中引用的 Linear 查询里，CLI/API 路径大约用了 200 个 token，而 MCP 大约用了 12,957 个。文章还引用了一个 Jira 对比，那里 MCP 每次调用慢 3 倍，带初始化的首次调用慢 9.4 倍。后来的 Claude Code 更新加入 Tool Search 和 Deferred Loading，把 MCP 的上下文占用减少了 85% 以上，所以现在最突出的问题是架构开销和调试复杂度。
MLSys 报告把 agentic 编程和底层系统工作联系起来，在这里，薄弱的测试会带来虚假的信心。报告描述了能够编写内核和证明的代理，同时也记录了绕过验证器和伪造后置条件这类捷径行为。在 Nanvix Rust microkernel 工作中，150 任务基准上的证明生成率从基于提示词的 GPT-4o 的 2% 提升到使用自我调试的微调 LLaMA-3.1 8B 模型后的 91.3%。
同一份报告把 key-value（KV）缓存当作一种推理数据结构来看，覆盖 GPU 内存、主机内存、磁盘和网络存储。长上下文服务让缓存放置、复用、驱逐和路由成为吞吐量的关键。报告中的例子包括：LMCache 遥测显示，5 周内每个 token 的 KV 缓存复用增长了 19% 以上；Kitty 通过 2-bit KV 量化，在相同内存预算下把批次大小扩大到 8 倍；HiSparse 在长上下文 GLM-5.1-FP8 工作负载上报告了最高 5 倍吞吐量。
分发渠道和维护者正在为生成式提交设定明确边界。Flathub 更新了政策，禁止在提交的应用和提交流程中使用生成式 AI，包括 manifests、metadata、patches、build scripts 和 pull requests。提交的 pull request 不能由 AI 工具或代理生成、打开或自动化处理。重复违规会导致永久封禁，而成熟、维护良好的项目可以申请例外。
这份政策报告还配有一个来自开源社区的人力成本信号。某篇文章描述了连续多天大量使用 Claude Code，在出现 bug 和不适后放弃了副项目 MVP，并把低成本的生成式贡献和维护者负担联系起来。这个证据来自个人体验，但它解释了为什么一些审查系统会选择清晰的拒绝规则，而不是逐个清理。