Agent 架构和一些架构的思考

和 Accio 的技术同学了解了下 Agent 的架构，目前是采取 Agent SDK+业务租户的方式进行，其中我觉得更有参考价值的是 Agent SDK 是如何建设的，主要分为以下几个模块：
1. Agent：包含 workflow agent、react agent、single agent，也会涉及到 agent 主从、层级关系等。我认为这个模块构成了 agent 架构的核心，要解决的问题是 agent 是如何解决问题、agent 和 agent 之间如何协作、以及如何对问题进行修正等。在这个模块里包含了 Plan/Eval 阶段，实际上成熟的架构可能需要把这个模块拆出来。
2. Memory：包含 STM/LTM、混合检索、上下文压缩，其中上下文压缩是所有模块的基础，再好的检索都会有 token 溢出或者注意力丢失的问题。这个可能是次重要的模块，本质是要构建从知识->检索->产出的过程。补充一点，如果是单一业务场景的话，业务知识会建设在 LTM 中以 QA 对、chunking 文档、平铺/层级/知识图谱的形式存储，但因为 Accio 架构需要适配多个业务场景，所以这里指的 STM/LTM 只是一种存储方法而非实际的存储内容。
3. Sandbox：包含沙箱生命周期管理、文件服务、命令服务等，这个构成了生产侧关键的安全隔离。
4. Prompt：prompt 构成了以什么指令去调用 function 和 skill 的问题，依然同上，这里指的是一种 Prompt 的方式而非实际的 Prompt 内容，实际 Prompt 的内容存储在各个业务应用侧。
5. Function：例如工具注册、调度等。
6. Skill：虽然在更广泛的语境中 skill 指的是 Function 编排，但在我们的架构中Skill=Rule+Code，为了解决上下文工程中超长窗口采取的渐进式披露。

对于 OPC 来说最重要的是知道如何用这些模块适配自己的业务场景，大概率这些模块都会选上，但或许侧重点不同。比如说如果是 coding agent 那么会在 plan 和 sandbox 模块做工多，因为代码生成的容错率低，需要先 plan 好才能去 code。再比如，如果是一个问答 agent 那么需要在 Memory 和 RAG环节做工多，即便是模型再聪明，基础的chunking 策略、混合检索召回率、rerank 精准度也会极大影响产出效果，所以要把知识库建好、索引好、方便输出任务。

之前的 Bet 总是，一个好的商业模式是高于一切的，但经历了这三四年的变化后发现，没有谁（产品、模型、资金）有护城河，而实际上真正好的商业模式的体现可能不是在 day1 而是在 day100。商业模式是奢侈品，多数创业公司要先用一个PMF 去解决如何活下来才能去谈商业模式的问题。所以现在看，商业模式看上去更像是一个锦上添花的作用，能帮助一个本来就能活的公司活的更好，而不是帮助一个本来就活不下来的公司活下来。

所以我认为现在的阶段有两件事情会很重要，1. 如何利用数据，2. 采用怎样的架构。我的浅显的理解，数据很重要是因为 scaling law遇到了 data wall、和高质量数据的短缺。架构很重要是因为一个好的架构可以更好的激发大模型的脑子，帮助它产出更符合用户预期的答案。比如我现在怀疑 dokie 这种 生ppt 产品应该就是在 prompt 方面下的功夫更大，因为实际上生成内容不是一件很难的事情，难的是如何拿到用户的 context。