简介与主要主题
我参加了 4 月 28 日至 29 日在旧金山举行的 AI 开发者大会 (AI Developer Conference)，并想在此记录我的笔记。这两天活动的主题是新生成式 AI（GenAI）时代的软件开发，特别是关注编码智能体（Coding Agents）以及软件工程的未来。
我在整个活动中观察到了几个主要主题：
- 编码智能体的演进以及软件开发生命周期（SDLC）的变化。
- 内存（Memory）、上下文工程（Context Engineering）和 Harness 工程（Harness Engineering），这些概念被多次讨论，且定义略有不同。
- 由 LangChain 创始人 Harrison Chase 倡导的“可观测性飞轮”（Observability Flywheel）概念。他将其描述为四个阶段：构建、测试、部署和监控，而“追踪”（Trace）位于中心，用于观察和改进飞轮。
- 人类技能发展以及帮助开发者适应这个快速变化的时代，这与主办方 deeplearning.ai（一家教育平台）的宗旨高度契合。
- 基于现场赞助商和演讲者的 AI 初创公司及行业格局观察。
软件工程的转变
许多讨论集中在编码智能体如何管理整个软件生命周期上。例如，CodeRabbit 展示了他们的 AI 代码审查平台。一个反复出现的挑战是，编码智能体本质上是无状态的——对于每一个独立的 session 来说，它们都像是一个新员工。共识在于：推理（Reasoning）不再是最难的部分；真正的挑战是上下文工程，即为智能体提供足够优质的上下文来完成工作。
吴恩达（Andrew Ng）的主题演讲深入探讨了这一转变。他解释说，现在的软件是由两种不同的积木构建的：AI 模块（如 LLM 和智能体工作流）和非 AI 模块（如传统的 UI 和数据库）。掌握这两者是新的核心竞争力。
他还提倡以 100% AI 编码为目标。理由是，即使你用 AI 编写了 80% 的代码，手动编写剩余的 20% 可能会花费更长的时间。识别最后 20% 中的瓶颈（可能是缺乏上下文）至关重要。由于 AI 让编写代码变得如此之快，瓶颈正在转移到生命周期的其他领域，如产品管理、法务、设计和市场。每个人都具备跨职能技能的小型 AI 原生团队，能够比传统的企业团队更快地克服这些障碍。
吴恩达概述了 AI 工程师不断演变的职位描述：
- 成为编排工作流的“智能体经理”（Agent Manager）。
- 掌握 AI 和非 AI 构建模块的集成。
- 培养强大的产品管理能力和产品感，以处理新的非编码瓶颈。
虽然许多人预言“职业末日”，但吴恩达非常乐观，专注于增强人类能力和创造新职位。就个人而言，我觉得真相介于两者之间：虽然我们没有面临全面被取代，但短期内确实看到了职位的裁撤。吴恩达还宣布了两个针对“并行技能发展”的产品：Context Hub（一个允许智能体获取最新上下文，如最新 API 文档的开源库）和 Codream（一个结合了可执行 JavaScript 和视频集成的、以人为本的学习工具）。
Harness 工程 vs. 上下文工程
关于智能体的心理模型有一场有趣的辩论。Harrison Chase 将 “Harness”（基座/挂载） 描述为模型自身无法提供的功能。他列出了智能体所需的六项能力：
- 持久地处理真实数据（需要文件系统和 Git）。
- 编写并执行代码（需要 Bash）。
- 安全执行和默认测试（需要沙箱环境）。
- 记忆和获取新知识（需要内存、网络搜索或 MCP）。
- 在长上下文中保持性能（需要压缩/Compaction）。
- 完成长程任务（需要 ReAct 循环、规划和验证）。
LangChain 已经开源了一个名为“Deep Agents”的代码库来解决这些问题。另一方面，来自 AWS 的 Mike Chambers 认为，“循环（Loop）”从来不是难点——“Harness”才是。他通过会话隔离、上下文管理、内存持久化、沙箱执行和可观测性来定义 Harness。我们看到像 AWS 这样的超大规模云厂商正在构建像 Bedrock AgentCore 这样的庞大工具，而初创公司则专注于细分的难点，这与行业构建微服务和云原生应用的过程非常相似。
深度探究：上下文工程与智能体搜索
上下文工程是一个巨大的瓶颈。Chroma 的 CEO Jeff Huber 使用了一个生物学类比：前额叶皮层（系统 2）很慢，而大脑的其余部分（系统 1）很快。智能体需要平衡读取和写入上下文，以防止“上下文腐化”（Context Rot）。
Huber 做出了一个精彩的区分：“Harness 工程” 是作为工具让智能体进行 自己的 上下文工程，而传统的上下文工程是由人类从外部编排的。Chroma 展示了“Context 1”，这是一个完全专注于快速、智能体化搜索的模型。他指出，在智能体搜索中平衡“探索与利用”（Explore and Exploit）仍然是一个未解决的问题。Huber 还对上下文工程的未来给出了三个预测：
- 它将是持续的（动态推拉）。
- 它需要快速。
- 它需要持续学习。
来自 Unblocked 的 Brandon Waselnuk 完美地阐述了上下文的重要性：“你的编码智能体只看到了你的代码，但你团队的架构决策存在于 Slack 和 Jira 中”。Unblocked 将智能体视为“入职第一天”的新人，并将其上下文引擎建立在六个支柱上：
- 统一系统上下文。
- 冲突解决。
- 定向检索。
- 数据治理。
- Token 优化。
- 个性化与相关性。
他们解决冲突的方法特别有趣。当检索到的上下文相互矛盾时，他们使用“社交图谱构建器”。如果某位工程师是集成测试专家，那么他们关于该主题的文档自然应该比其他来源具有更高的优先级——就像人类的直觉判断一样。
AI 初创公司版图
观察 70 家赞助商是对行业的一次极好调研。我的分析显示，大约有 13 家种子前（Pre-seed）和种子轮公司，6 家 A 轮，3 家 B 轮，5 家后期阶段，以及大约 8 家成熟的私有公司。资金正大量流入文档解析、RAG/数据库、智能体代码审查和编排领域。
有三家初创公司给我留下了比较深的印象：
- Band AI (Thenvoi)：非常有趣的方法，本质上是在构建“智能体版的 Slack”，以处理多智能体系统。
- AI21：他们的会议主题“终结手动调优”（End to Manual Tinkering）介绍了 Maestro 框架。他们认为，与其手动调整参数，不如引入神经网络对其建模，以获得巨大收益。在延迟、成本和准确性中你只能选其二，但 Maestro 通过两阶段过程（离线动作模型训练和推理时运行时动作选择），通过异构集成动态平衡它们。
- Veris.AI：他们专注于仿真和沙箱。我对他们的可扩展性持保留意见。他们的演示是一个使用 Epic API 的简单医疗分诊智能体。对于复杂的企业级智能体，我怀疑他们是否仅凭数据模式（Data Schema）就能实现高保真仿真。但总的来说，这是一个充满希望的领域。
