这些工具的差异很大，但共同结构很清楚：人不一定先打开文件、定位函数、手动改几行，而是描述目标，让 Agent 修改一组文件，再通过 差异对比、测试结果、运行日志和评审流程判断是否接受。因为我已经有一个技能可以生成幻灯片、XLSX 和 DOCX，所以我最开始 只是想把 DOCX、XLSX、PPTX 打开，能预览、搜索、缩放，未来可以更方便添加更多的功能。编辑不是重新生成一份文档，而是在已有现场里工作

或许这个可以当成是你的毕业设计又或者你可以用它来控制你想控制的东西，总之你可以用它来做一个最小的物联网系统。不过，在这里可能没有那么复杂的功能，因为强调的是最小。BareMinimum，这也是为什么我没有改Arduino上面的工程名的原因，因为它是最小的，(PS：大家都懂的，如果玩硬件）。物联网，这个东西一直很复杂，也不是很复杂，只是从硬件到软件涉及到的东西过多了，不止一点点。

OpenAI 近期总结 Codex 的长任务经验时，也把 loop 明确写成 plan、edit code、run tools、observe results、repair failures、update docs/status、repeat，并强调长任务之所以更可靠，不在于一个更长的 prompt，而在于 harness 提供了结构化上下文和清晰的 "done when" 例程。所以，我们要建设

Spec 仍然负责边界、约束和验收，但大量真正改变实现走向的内容， 已经留在 Codex、Claude Code、Qoder 这些 Agent 的 session 历史里：一次失败的尝试，一个临时收掉的交互，一次 API 结构调整，一组被反复读写的文件。但 Session 的问题也同样明显。所以我后来关心的事情也跟着变了：session 里的局部过程能不能重新推回当前功能，Spec、页面、API

于是，多 Agent 时代的核心问题不只是“如何让 Agent 更能干”，而是如何为人的注意力设计一套 Harness：哪些事情应该打断人，哪些应该静默推进，哪些需要聚合，哪些必须升级。但当 Qoder、Codex、Claude Code 这类工具开始支持长任务、后台执行、多线程会话、权限请求和结果审查后，真正的难点变成了：多个 Agent 同时工作时，人类如何看住它们。但在 Agent 时代，每

这些 Store 提供了 状态持久化能力——如果某个 CRAFTER 陷入死循环（类似 AutoGen 常被诟病的对话混乱），或者发生网络中断，Routa 的架构能够依靠结构化的 Task 和 Stores 从断点恢复执行，而不是从头开始消耗 Token。这展现了 Routa 在企业级部署时对。PS：在设计 Routa，我们（我和 AI）参考了 Augment Code 的 Intent 协作体系

阶段，团队主要通过对话界面或简单工具使用 AI。通过逐步建立人与 AI 的协作能力，团队可以更好地利用 AI 的潜力，同时保持软件系统的质量与可持续演进。在越来越多的团队中，AI 不再只是提供建议，而开始参与实际开发任务，例如生成模块、运行测试、修复错误，甚至创建 Pull Request。然而，在许多组织中，人们仍然把 AI 编程理解为一种工具升级：更聪明的 IDE 插件、更强大的代码生成器，或

在代码层面，扫描依赖的是静态分析与数据流追踪的结合。分析会从典型输入源开始，例如 HTTP 请求参数、RPC 调用或 URL 查询字符串，然后沿着代码路径追踪数据的传播过程，直到抵达危险操作，例如 shell 执行、HTML 渲染或外部网络请求。与传统的安全扫描不同，这些报告不仅包含漏洞列表，还提供了完整的攻击路径、动态验证结果以及可应用的修复补丁。从 Codex Security 的扫描分析中得

这些工具的差异很大，但共同结构很清楚：人不一定先打开文件、定位函数、手动改几行，而是描述目标，让 Agent 修改一组文件，再通过 差异对比、测试结果、运行日志和评审流程判断是否接受。因为我已经有一个技能可以生成幻灯片、XLSX 和 DOCX，所以我最开始 只是想把 DOCX、XLSX、PPTX 打开，能预览、搜索、缩放，未来可以更方便添加更多的功能。编辑不是重新生成一份文档，而是在已有现场里工作

TL；DR：我们需要一个新的框架、胶水层，来帮助我们适配生成式 AI 的输出，以及解决流式数据传输的问题。在过去几个月里，我们一直在项目上探索：如何设计更好的架构，以将业务流程和开发流程中的各类智能体结合起来，进一步释放生成式 AI 的潜力？诸如于面向 IDE、DevOps、Team AI 等多个不同消费端的智能体。在这个过程中，浮现了一种新的架构模式：流式 BFF。流式 BFF（Streamin