作者从 FDE（企业 AI 交付）视角，用同一份企业数据和 18 条压力测试对比了 Dify 与腾讯云 ADP 4.0。Dify 搭建快速灵活但生产环境交付环节仍需大量人工处理；ADP 4.0 将构建、接入、分发、治理统一进 AgentOps 平台，在高风险动作受控 Workflow、权限管理、知识库冲突处理、Skill 安全审查、Connector 接入及运行审计方面表现突出，还支持自然语言生成应用骨架和 Claw 开放式数据分析。结论是：个人快速搭建选 Dify/n8n，需要接企业系统、控权限、持续运维的交付项目更适合 ADP，能交付生产环境的 FDE 才能赚到企业的钱。
文章指出当前企业级AI Agent热潮中FDE（前向部署工程师）大热，本质是产品缺位的表现：企业想把Agent用于业务，但Agent不懂企业运作方式，懂业务的人又无法轻易教会Agent。作者基于Palantir前向部署AI工程经验，提出通过ContextOps持续将运营证据和专家判断转化为可测试、可审批的指令，并用“可执行覆盖率”衡量Agent能否在无需人工补判的情况下正确处理案例。学习循环让每次升级都沉淀为流程知识，使企业拥有而非租借这套能力，比微调模型更可控可靠。
作者分享在人工智能小镇开展 FDE（一线实施）的第三周实践战报。第一周通过升级硬件、使用 workbuddy 专家库，让员工自主完成平面设计、课程AI化和知识库建设（采用带索引的Grep而非RAG）；第二周引导员工从Workflow转向自建Agent，通过待办Agent与咨询师Agent打样，结合飞书聊天群与话题群实现管理与交付，并输出提示词由Coding Agent完成部署；第三周计划搭建内网工具分享平台，实现Agent打包上传、局域网共享。作者强调只负责培训指导与验收，倡导让员工自己动手用AI解决业务痛点。
文章从AI对话缺乏长期记忆的痛点切入，系统讲解了个人知识库的作用、分类与搭建方法。作者介绍了两大主流方案：以检索为中心的RAG知识库和以持续维护页面为中心的LLM Wiki知识库。RAG部分通过Dify演示了从资料上传、切片、混合检索索引建立到Agent接入的完整流程；LLM Wiki部分则介绍了Karpathy提出的三层结构（raw sources、wiki、schema），强调Markdown页面对AI友好且透明可查。最后作者分享了自己结合两者优势的混合方案，帮助读者根据实际需求选择合适的知识库路线。
作者认为市面上动辄上万元的 FDE（Forward Deployed Engineer）培训完全没必要报课，只需学习几个开源项目即可：fdeops 定位为 FDE 第二大脑，可接入 Claude Code、Cursor 等 Agent，让访谈纪要和交付清单可直接被引用；fdestack 将工作流拆成可复用 Skills；openfde 提供本地优先工作区，作为可引用的作战记忆；fde-guide 补充方法论和流程。建议做 ToB 交付、驻场、AI 落地的人按 Skills 管流程、仓库管记忆的思路，先装 fdeops 底座，再按团队技术栈补齐。
文章探讨企业在 AI 落地中的真实场景：高容错、全自动闭环的高价值场景其实很少，AI 应服务于商业上下文而非替代决策。作者提出 AI 落地的三个微观切面：商业上下文组装器（压缩决策时间）、非结构化数据转换插头（结构化清洗入 CRM）、内部经验的平权分发（RAG 知识库）。针对传统企业“隐性知识”断层——经验锁在老员工脑中、缺乏数据沉淀——给出三种破局策略：过程拦截式沉淀、引入 FDE 人工提取上下文、让 AI 成为反向采访者。结论是 AI 应做 Copilot 而非 Autopilot。
文章介绍中小企业如何借鉴 Palantir 的核心理念——统一业务对象、受控执行动作、可审计权限沙箱，用 PostgreSQL、MCP/OpenAPI、AI 中间件和 n8n 等低成本组合搭建轻量级本体系统。作者提出四层技术架构和四步落地路径：建立语义层抽象视图、将写操作封装为强约束 Action Schema、利用中间件编排意图路由与规则门禁、引入人类在环与异步审批。最后给出三个避坑原则：不盲目上知识图谱、业务逻辑放代码而非 Prompt、从小场景建立局部闭环。
本文作者基于 FDE/To B 企业 AI 交付实战经验，系统拆解了小团队从 0 到 1 做企业 AI 服务的完整链路：线索、初筛、现场调研、需求边界、报价、SOW、开发交付、测试验收、交接回款与复盘复用十步。文章强调小团队卖的不是 AI 技术而是可验收的结果，详细讲解了获客路径、客户筛选标准、现场需求调研方法、分阶段报价策略、SOW 工作范围说明的写法、测试集设计以及需求变更处理，帮助 FDE 小团队把模糊的老板想象转化为双方可理解、可测试、可验收的交付成果。
作者分享了重构 Hermes 多代理系统的经验，批评了当前将角色扮演误认为真正多代理系统的现象。文章提出了三种架构模式：一次性子代理、永久专家配置和群体，并强调了编排者的重要性。作者以 Wu-Tang Clan 成员命名不同职责的代理，展示了严格的权限边界和清晰的职责分配。
本文介绍了如何利用 Obsidian、Markdown、GitHub 和 AI（Codex）快速搭建一个同步的知识库。文章建议新手先不要追求复杂的 RAG 和向量数据库，而是使用 Obsidian 结合 Git 插件进行本地与云端（GitHub）的免费同步。文中还提供了小红书及网页内容剪藏插件的推荐，实现内容的快速收集与 AI 辅助整理。
本文是关于在 2026 年构建多 Agent 工作流的深度指南。文章对比了单 Agent 与多 Agent 系统的区别，详细解析了 Claude Code 的三种编排原语（子代理、团队、动态工作流）及六大核心拓扑结构（顺序流水线、协调者-工作者、并行发散、生成器-验证器、共享状态、辩论模式）。同时探讨了如何设计 Agent 间的通信、避免上下文污染以及处理系统失败模式。
文章深度剖析了开源项目 Multica（GitHub 15.4k stars）的多智能体记忆系统架构。与普遍依赖向量数据库的方案不同，Multica 采用了基于 PostgreSQL 和 JSONB 的纯关系型数据库设计，通过 Issue、Skill、Agent Task Queue 等六张表实现状态管理、技能积累和工作空间隔离。作者详细梳理了任务从创建、快照生成到 Agent 执行的完整流程，并指出对于编码类任务，明确关联优于模糊检索，同时探讨了该架构在上下文持久化和跨工作空间记忆方面的局限性。
本文介绍了 Andrej Karpathy 提出的“LLM Wiki”个人知识库模式，即利用 AI 将原始资料编译成持久化的 Wiki，解决了传统 RAG 方案无法保留上下文和维护关联的痛点。作者详细解析了 Karpathy 的“Raw/Wiki/Schema”三层架构，并演示了如何利用开源桌面 AI Agent 工具 nexu 落地该模式，实现在微信随手入库、多模型切换及与 Obsidian 的协同工作，从而构建一个由 AI 维护的个人第二大脑。
