企业级 AI Agent 系统：需求分析、核心挑战与架构设计目标

从通用 Agent 的能力边界出发，探索事件驱动、多角色协作、共享记忆与可靠执行的企业级 Agent 架构。

系列：从零构建企业级 AI Agent · 第 01 篇

一、引言：通用 Agent 已经很强，为什么还要自己开发？

随着大模型能力不断提升，AI Agent 正在从简单的对话助手，演进为能够理解任务、调用工具、执行操作的智能系统。

今天，通用 Agent 已经能够完成相当复杂的工作，例如编写代码、分析文档、搜索资料、操作软件，甚至连续执行多步骤任务。

与此同时，LangGraph、OpenAI Agents SDK 等开发框架，以及各类企业 Agent 平台，也在不断降低 Agent 的开发门槛。

这引出了一个值得思考的问题：

既然通用 Agent 已经如此强大，企业为什么还需要建设自己的 Agent？

1.1 从一个真实的研发协作场景说起

假设一家互联网公司的研发团队，日常使用以下工具：

• 云效：管理需求、Bug 和研发任务。
• 飞书：测试人员反馈问题、研发人员讨论和协作。
• GitLab：托管代码、管理 Merge Request。
• CI 平台：执行单元测试、集成测试和代码检查。

在传统研发流程中，测试人员发现问题后，通常需要在群里反馈或创建 Bug，再由相关负责人分析、修复、提交代码，最后等待测试验证。

这个过程存在大量重复性工作：

• Bug 可能已经存在，但测试人员不知道。
• 同一个问题可能在不同群聊中反复出现。
• 研发负责人需要人工整理问题并确定优先级。
• 开发人员需要反复搜索历史故障、代码和技术文档。
• 修复完成后，还需要人工同步进度、通知测试人员。
• 部分问题因为沟通遗漏而长期无人跟进。

现在设想一个能够持续参与研发协作的 Agent 系统。

当测试人员在飞书群中反馈：

订单服务的退款接口偶尔返回 500，云效上之前好像也提过这个问题，麻烦后端看一下。

Agent 可以主动完成以下工作：

1. 识别这是一条潜在的 Bug 反馈。
2. 查询云效，判断是否已经存在相同或相关缺陷。
3. 关联代码仓库、服务归属和历史修复记录。
4. 确定负责人，并主动通知。
5. 分析相关代码，尝试定位问题原因。
6. 在授权范围内创建修复分支，修改代码并运行测试。
7. 创建 Draft PR，附上问题分析、修改内容和测试结果。
8. 持续跟踪 PR 审核、CI 和测试反馈。
9. 在问题解决后，将经过验证的修复经验沉淀为团队记忆。

这不再是一次简单的问答，而是一个由业务事件触发、能够持续执行、跨系统协作的长期任务。

1.2 通用 Agent 与企业 Agent 的关键区别

对于通用模型而言，理解 Bug 描述、分析代码甚至生成补丁，都已经是相对成熟的能力。

真正困难的是：

• Agent 如何持续感知企业内部发生的事件？
• 如何获得飞书、云效和代码仓库的访问权限？
• 如何知道哪个项目、哪个模块属于哪个负责人？
• 如何避免对同一个 Bug 重复创建任务或 PR？
• 如何在多个 Agent 之间共享任务上下文？
• 如何利用历史修复经验，同时避免错误记忆影响判断？
• 如何在执行中断后恢复任务？
• 如何保证代码修改不会越过企业的安全边界？
• 如何验证 Agent 真的修复了 Bug，而不只是提交了一段代码？

这些问题已经超出了单纯的模型推理能力。

通用模型解决的是智能能力的供给问题，企业 Agent 还需要解决智能能力如何融入组织、业务流程与软件工程体系的问题。

因此，企业需要的通常不是重新训练一个更聪明的模型，而是建设能够整合内部系统、理解业务上下文、执行长期任务并接受治理的 Agent 能力。

但需要强调：

企业拥有自己的 Agent 能力，不等于必须从零自研 Agent Runtime。

采购成熟产品、基于现有平台定制、使用开源框架开发以及自研核心组件，都是合理选择。

二、市场需求：企业究竟在招聘什么样的 Agent 工程师？

判断一项技术的实际需求，不能只看技术社区的热度，还需要观察企业愿意投入哪些研发资源。

招聘信息是一个有价值的观察窗口。

2.1 从企业招聘 JD 看 Agent 技术能力

以滴滴官方招聘岗位 AI Agent 基建平台架构师 为例，岗位职责涉及：

• Agent 创建、配置、版本、发布及运行托管等全生命周期管理。
• Agent 编排与运行时能力，包括模型、Prompt、知识库、MCP、工作流、记忆和任务调度。
• 日志追踪、异常恢复、灰度发布、权限隔离和稳定性建设。
• 高并发、分布式运行时的性能优化。
• 评估 LangGraph、DeepAgents 等框架，并结合业务进行技术选型。

这些要求说明，企业正在将 Agent 视为一种需要长期维护的软件系统，而不仅仅是一次模型 API 调用。

资料来源：滴滴招聘——AI Agent 基建平台架构师

京东的 Agent 平台方向岗位也涉及业务 Agent、工具集成、MCP、Agent 协作及工程问题定位。

资料来源：京东招聘——Agent 平台方向

结合部分公开岗位描述，可以将相关研发需求归纳为以下几类：

以上是对部分公开招聘样本的定性分析，不是经过统计抽样的全市场岗位占比结论。岗位发布也不能直接证明相关能力已经在企业内部成熟落地。

不过，这些需求揭示了一个重要趋势：

Agent 开发正在从模型调用和 Prompt 设计，向运行时、数据工程、权限治理和软件可靠性等方向延伸。

对于具有传统后端、分布式系统和企业业务研发经验的工程师，这些领域同样是进入 Agent 工程的重要切入点。

三、大厂实践：企业 Agent 平台正在解决什么问题？

招聘需求反映企业希望获得的研发能力，而云平台和企业软件厂商的公开架构，则展示了另一种视角：当 Agent 被广泛引入企业时，需要补充哪些基础设施？

3.1 Google Cloud：从模型平台到 Agent 平台

Google Cloud 在 Gemini Enterprise Agent Platform 中，将平台能力概括为构建、规模化运行、治理和优化 Agent。

除了模型本身，平台还强调 Agent Identity、Registry、Gateway、Memory、Evaluation 和 Observability 等能力。

当企业只有一个 Agent 时，开发者可能只需要关注模型、工具和 Prompt。

当企业拥有大量 Agent 时，就需要回答：

• Agent 由谁创建和管理？
• 哪个 Agent 可以访问哪些工具？
• Agent 的身份和权限如何维护？
• 如何追踪一次跨系统任务？
• 如何统一评估、部署和更新？

这些问题更接近平台工程，而不是单个 AI 应用的开发。

资料来源：Google Cloud——Introducing Gemini Enterprise Agent Platform

3.2 Microsoft：Agent 需要自己的身份和治理机制

Microsoft 的 Agent 相关架构强调 Agent Identity、委托授权以及企业治理。

传统企业软件主要管理人的身份和权限。Agent 出现之后，企业需要进一步考虑：一个由用户发起、可能持续执行并调用多个系统的 Agent，究竟应该以什么身份行动？

例如：

研发人员 A 可以查看自己负责的代码仓库，但不能访问其他团队的私有仓库。

当研发人员 A 委托 Coding Agent 修复 Bug 时，Coding Agent 不应该因为自身拥有代码工具，就自动获得修改所有仓库的权限。

因此，需要区分：

• 用户身份与用户权限。
• Agent 身份与 Agent 自身的能力范围。
• 用户授予 Agent 的委托权限。
• 目标业务系统最终执行的授权校验。

Agent 的执行权限不应该由模型通过 Prompt 自行决定。

资料来源：Microsoft Agent 365——Agent Identity

3.3 AWS：工具调用需要独立的策略执行边界

AWS Bedrock AgentCore 的 Gateway 和策略机制强调，对 Agent 工具调用进行独立授权和拦截。

原因很直接：Agent 的工具调用具有一定动态性。

同样一个用户请求，模型可能选择不同工具、不同参数和不同执行顺序。

因此，系统不能仅仅通过一段 System Prompt 告诉模型“不要执行危险操作”，就认为安全问题已经解决。

更合理的设计是：

模型负责提出行动，程序负责验证行动，业务系统负责维护最终业务约束。

资料来源：AWS——Securing AI Agents with AgentCore Gateway Policies

3.4 Salesforce：Agent 是企业 IT 架构的组成部分

Salesforce 在 The Agentic Enterprise 架构中，将 Agent Runtime、企业语义层、应用集成、工作流编排、可观测性和安全治理放在统一架构下讨论。

传统企业系统主要围绕人使用应用程序开展工作，而 Agent 使软件能够在授权范围内参与任务判断与执行。

但企业原有的 ERP、CRM、财务和订单系统并不会因此消失。

Agent 更可能通过标准化接口和业务服务与这些系统协作，而不是直接取代所有既有业务逻辑。

资料来源：Salesforce Architects——The Agentic Enterprise

3.5 从这些实践得到的启示

综合这些官方资料，可以看到几个共同方向。

第一，模型与企业控制能力正在分层。

模型提供理解、推理与规划能力；企业系统提供身份、权限、业务数据、操作接口和治理机制。

第二，Agent 不应绕过已有业务系统。

业务规则、交易约束和最终数据一致性仍应由确定性的业务服务保障。

第三，Agent 的运行状态、记忆和权限需要独立治理。

一次对话的上下文，并不足以代表完整的企业任务状态。

第四，Agent 不应该只能被动响应。

对于研发协作、运维、客服和业务流程等场景，Agent 可以通过事件订阅、任务调度和状态管理主动参与工作。

但这种主动性必须受到明确的权限、触发条件和执行边界约束。

当然，厂商官方架构描述的是其产品设计方向，不能直接等同于所有客户的实际生产效果。具体收益仍需要通过真实业务指标验证。

四、企业级 Agent 的七个核心技术挑战

基于上述需求和研发协作场景，可以将企业 Agent 的关键工程问题归纳为七个方面。

4.1 主动感知：从被动对话到事件驱动

传统 Chatbot 通常由用户主动发起请求。

但在企业研发协作中，很多任务是由业务事件触发的。

例如：

• 云效新增或更新 Bug。
• 飞书测试群出现新的问题反馈。
• PR 审核状态发生变化。
• CI 执行失败。
• 测试人员反馈问题仍然存在。

系统需要持续感知这些事件，并判断是否应该创建任务、更新已有任务或通知相关人员。

这里首先涉及传统事件驱动架构中的问题：

• Webhook 与 Polling 如何选择？
• 重复事件如何去重？
• 乱序事件如何处理？
• 外部系统不可用时如何补偿？
• 多个事件如何关联到同一个 Bug？
• 如何避免反复触发相同的 Agent 任务？

一个重要的设计原则是：

事件接入、去重、状态管理等确定性工作，应优先由传统程序完成；需要语义理解和不确定性判断的环节，再交给模型。

例如，飞书消息是否属于 Bug 反馈，可以使用模型分类；但事件 ID 去重不需要 LLM。

此外，群聊消息可能包含敏感信息、个人讨论或与研发无关的内容，因此必须明确采集范围、访问授权、保留策略和数据最小化原则。

4.2 多用户、多角色与权限边界

企业中存在不同的组织、部门、岗位和审批职责。

同一个 Agent 面对不同用户时，能够访问的数据和执行的操作可能完全不同。

例如：

• 测试人员可以提交 Bug、查询测试任务。
• 研发人员可以查看授权范围内的代码仓库和任务。
• 技术负责人可以管理项目任务、审核代码变更。
• CI 服务身份可以执行限定范围的自动化测试。

这里至少存在两类角色：

用户角色（User Role）：决定用户在组织中的业务权限。

Agent 角色（Agent Role）：决定 Agent 承担什么任务、具备什么专业能力。

二者必须分开。

一个负责代码修复的 Agent，不应该天然拥有全部代码仓库的修改权限；一个 Supervisor Agent 将任务交给其他 Agent，也不应该自动扩大原始任务的授权范围。

对于主动触发的任务，还需要明确自动化服务身份、任务授权来源以及允许执行的操作范围。

因此，企业 Agent 的权限检查必须覆盖数据采集、知识检索、上下文构建、工具执行和任务恢复等环节。

4.3 多层记忆与组织知识共享

Agent Memory 不应该简单理解为“将聊天记录保存到向量数据库”。

企业中的信息具有不同来源、作用域、可信度和生命周期。

从内容角度，可以研究：

• Semantic Memory：业务事实、项目知识和技术约定。
• Episodic Memory：历史 Bug、任务执行经历和修复结果。
• Procedural Memory：可复用的排查方法、操作流程和修复经验。

从访问范围角度，可以划分：

• 个人私有记忆。
• Agent 工作记忆。
• 项目共享记忆。
• 团队共享记忆。
• 组织级共享记忆。

这两个维度相互独立。

例如，一次退款接口异常的修复记录属于 Episodic Memory，但它可能只允许订单研发团队访问。

企业记忆还需要处理更复杂的问题。

记忆如何形成？

Coding Agent 推测某段代码存在并发问题，是否可以直接保存为长期事实？还是需要通过测试和人工审核后才能确认？

记忆如何共享？

某个开发人员的排查经验什么时候可以升级为团队知识？共享时是否需要删除客户数据、密钥或内部敏感信息？

记忆如何更新？

当新的修复结论推翻旧结论时，是覆盖、保留版本，还是标记旧结论已失效？

记忆如何撤回？

当用户删除信息或组织权限发生变化时，原始数据、向量索引、摘要和缓存如何同步失效？

还需要区分权威业务数据与 Agent 记忆。

例如，代码模块负责人应该优先从明确维护的 CODEOWNERS、项目配置或任务系统中获取，而不是仅凭历史聊天记录猜测。

这些问题决定了企业记忆系统能否被信任。

4.4 多 Agent 协作与任务编排

研发协作涉及多个不同的专业环节。

例如，一个 Bug 的处理可能需要：

1. Triage Agent：识别、归类和关联缺陷。
2. Diagnosis Agent：分析代码、日志和历史问题。
3. Coding Agent：修改代码、运行测试。
4. Coordinator：管理任务状态、通知负责人并跟踪反馈。

但需要警惕一个误区：

业务存在多个角色，不代表技术上必须使用多个 LLM Agent。

例如，负责人查询可以由确定性服务完成；任务状态更新可以由 Workflow 负责；只有复杂的代码分析与修复才可能需要专门的 Coding Agent。

因此，多 Agent 架构应该回答：

• 为什么单 Agent 无法满足需求？
• Agent 之间传递什么状态？
• 如何避免重复工作和循环委派？
• 任务交接时如何保持用户授权？
• 如何判断协作带来的收益超过额外成本？

我们不应该为了展示 Multi-Agent 技术而强行拆分多个 Agent。

4.5 Coding Agent：代码执行与安全边界

自动修复 Bug 是整个研发协作场景中最有价值、也最需要谨慎设计的部分之一。

Coding Agent 可能需要：

• 读取代码仓库。
• 搜索相关文件和调用链。
• 修改代码。
• 安装依赖。
• 执行测试。
• 提交 Git Commit。
• 创建 Draft PR。

这些操作涉及真实的代码执行和外部副作用，因此需要考虑：

仓库与分支权限。

Agent 只能访问授权仓库，默认不直接修改受保护分支。

命令与网络权限。

不能将模型生成的任意 Shell 命令视为可信输入；需要对执行能力、网络访问和敏感凭据进行约束。

代码质量验证。

单元测试通过并不意味着 Bug 已修复。还需要结合回归测试、代码审查和原始问题的复现条件。

人工审核。

第一阶段可以允许 Agent 在限定条件下创建 Draft PR，但不自动合并或部署生产环境。

这也带来一个重要的评估问题：

成功创建 PR，不等于成功修复 Bug。

4.6 长期任务与可靠执行

从 Bug 发现到最终解决，可能持续数小时甚至数天。

例如：

• 周一：测试人员反馈 Bug。
• 周二：Agent 完成分析并创建 Draft PR。
• 周三：开发人员审核，提出修改意见。
• 周四：Agent 根据反馈更新补丁。
• 周五：CI 通过，测试人员完成验证。

这是一个长期存在的任务，而不是一次 LLM 请求。

系统需要支持：

• 任务状态持久化。
• 等待外部事件。
• 任务暂停、恢复和取消。
• 工具执行超时。
• 重复事件处理。
• 重启后的任务恢复。
• 外部副作用的结果核验。

例如，Agent 调用 Git 平台创建 PR：

1. PR 已成功创建。
2. 网络连接发生超时。
3. Agent 没有收到成功响应。

此时直接重试，可能创建重复 PR。

因此，需要通过幂等标识、关联查询或人工核查确认外部操作结果。

任务状态恢复，不等于外部业务副作用可以安全重放。

这也是企业 Agent Runtime 与传统分布式系统可靠性设计的重要交汇点。

4.7 可观测性、评估与成本控制

传统系统可以通过错误率、吞吐量、延迟和资源利用率等指标判断运行状态。

Agent 还需要回答：

系统运行成功，是否意味着任务完成正确？

例如，一个 Agent 成功读取代码、生成补丁、运行测试并创建 PR，但它修改了错误的模块，或者仅仅绕过了失败的测试。

从工具执行角度看，所有调用可能都成功了；从业务角度看，任务仍然失败。

因此，企业 Agent 需要同时建立：

技术指标：延迟、Token 消耗、工具失败率、资源利用率、任务恢复情况。

行为指标：Bug 识别准确率、工具选择正确率、任务步骤合理性、记忆召回质量、权限违规次数。

业务指标：有效 Bug 发现率、重复任务率、修复成功率、PR 审核通过率、人工接管率、平均处理时间和单位任务成本。

评估不应该等到项目开发完成后才补充，而应该从最小可运行版本开始建立。

五、建设企业 Agent：应该采购、定制还是自研？

讨论企业为什么需要自己的 Agent，还必须回答一个现实问题：企业是否真的应该自己开发？

答案并不总是肯定的。

即使决定自研，也不意味着所有组件都应该自行实现。

模型推理、Embedding、向量检索、工作流框架、MCP 协议、可观测性基础设施，以及 Coding Agent 本身，都可以优先考虑成熟方案。

更合理的建设原则是：

对通用能力优先复用，对企业差异化能力重点建设，对关键架构决策进行验证。

这里还需要考虑长期总拥有成本，包括研发投入、部署维护、模型调用、合规成本、故障处理和后续升级。

自研带来的灵活性，必须能够覆盖它增加的复杂度。

六、项目定位：事件驱动、多角色与共享记忆

基于前面的研究，可以将企业研发协作 Agent 的实践方向定义为：

一个以研发协作为实践场景，支持事件驱动、多角色协作、权限感知共享记忆与可靠任务执行的 Agent 系统。

它不以重新实现一个通用大模型或完整 Coding Agent 为目标，而是研究如何将现有智能能力组织成能够持续参与企业研发流程的系统。

6.1 三个核心研究问题

问题一：Agent 如何主动感知事件并协调多个角色？

研究事件接入、任务触发、Agent 分工、任务交接和权限传播。

问题二：多个角色如何共享可信记忆？

研究记忆分类、所有权、作用域、提取、检索、冲突、撤回和生命周期。

问题三：Agent 如何可靠地执行长期任务？

研究状态持久化、工具调用、审批、幂等、结果核验、失败恢复和审计。

6.2 初步逻辑架构

┌───────────────────────────────────────────┐
│              Enterprise Sources           │
│                                           │
│     云效 Bug / 飞书消息 / Git / CI 事件      │
└─────────────────────┬─────────────────────┘
                      │
┌─────────────────────▼─────────────────────┐
│        Event Ingestion & Normalization    │
│                                           │
│   Webhook / Polling / 去重 / 关联 / 授权      │
└─────────────────────┬─────────────────────┘
                      │
┌─────────────────────▼─────────────────────┐
│        Agent Orchestration & Runtime      │
│                                           │
│    Triage / Diagnosis / Coding            │
│    Task / Workflow / State / Checkpoint   │
└───────────────┬───────────────┬───────────┘
                │               │
┌───────────────▼───────┐ ┌─────▼───────────┐
│   Memory & Context    │ │  Tool / MCP     │
│                       │ │                 │
│ Personal / Team / Org │ │ 云效 / 飞书 / Git │
│ Retrieval / Lifecycle │ │ CI / Coding     │
└───────────────┬───────┘ └─────┬───────────┘
                │               │
┌───────────────▼───────────────▼───────────┐
│       Governance & Infrastructure         │
│                                           │
│ Identity / Policy / Model / Storage       │
│ Observability / Evaluation / Security     │
└───────────────────────────────────────────┘

这只是逻辑能力划分，不代表最终必须采用微服务架构，也不代表每个模块都需要独立部署。

云效、飞书、Git 平台和 Coding Agent 应尽量通过适配器接入，避免核心 Runtime 与某个产品强绑定。

具体实现仍需要经过技术调研和 PoC 验证。

6.3 关键架构设计目标

这些目标还不是已实现功能，而是后续设计和验收的依据。

七、MVP：从 Bug 发现到代码修复的研发协作闭环

第一阶段不追求通用平台的完整性，而是选择一个能够覆盖核心问题的真实研发场景。

场景：主动收集 Bug、关联测试反馈、协调负责人，并在授权范围内完成代码修复与 PR 提交。

为了控制复杂度，项目将分阶段建设。

7.1 V1：缺陷感知与协作

第一阶段重点解决：

• 接收云效 Bug 和飞书测试反馈。
• 统一事件模型。
• 识别潜在缺陷并关联已有 Bug。
• 查询项目、模块和负责人。
• 创建持久任务并主动通知。
• 检索相关历史问题和团队记忆。
• 记录完整处理过程。

这一阶段重点验证事件驱动、权限、任务状态和记忆检索。

7.2 V2：缺陷分析与自动代码修复

在 V1 的基础上，增加：

• 关联代码仓库和技术文档。
• 使用历史修复经验辅助分析。
• 接入成熟 Coding Agent。
• 在授权的任务分支中修改代码。
• 运行单元测试与静态检查。
• 创建 Draft PR。
• 记录修复证据与执行结果。

这一阶段重点验证 Coding Agent 集成、执行安全、代码质量与自动化评测。

7.3 V3：持续跟踪与多 Agent 协作

进一步支持：

• 跟踪 PR 审核意见。
• 处理 CI 失败事件。
• 根据反馈更新任务。
• 在授权范围内重新执行修复。
• 持续跟踪测试验证结果。
• 将经过确认的修复经验沉淀为团队记忆。

这一阶段重点验证长期任务恢复、多 Agent 协作、共享记忆与完整研发闭环。

7.4 MVP 的验收标准

为了避免项目变成只有演示效果的 Demo，需要设计可重复的测试。

初期可以通过示例代码仓库、预置 Bug、模拟飞书消息和云效数据构建可复现的测试环境，不依赖真实企业生产系统。

具体指标和阈值应在实现及基准测试后确定，不提前宣称生产级可靠性。

八、第一阶段明确不做什么

项目最容易遇到的问题之一，就是不断扩展功能范围。

因此，需要明确 V1 的非目标。

不自研基础大模型。 优先复用现有模型和推理服务。

不预设必须自研 Agent Runtime。 先研究成熟框架，再根据需求决定是否需要扩展或替换。

不从零开发完整 Coding Agent。 优先研究现有代码智能体的集成方式。

不追求无限自主执行。 主动执行必须受到明确约束。

不强制所有业务使用 Multi-Agent。 简单任务优先使用简单方案。

不建设完整企业 SaaS 管理平台。 第一阶段重点验证核心执行、权限和记忆机制。

不自动合并 PR 或部署生产环境。 初期只创建 Draft PR，并保留人工审核。

不把架构设计当作已验证成果。 所有关键结论都应有实现、测试或公开证据支持。

九、开发与写作：让技术研究成为项目的一部分

这个项目还有一个重要目标：通过公开技术研究，建立系统性的 Agent 工程知识体系。

开发过程与技术文章可以结合，但不应把文章写成简单的开发日志。

每个重要技术专题尽量遵循相同的过程。

第一步：研究问题。

理解业务需求、技术背景和已有解决方案。

第二步：比较方案。

研究主流框架、官方文档、开源源码、社区 Issue 及不同架构的适用条件。

第三步：验证假设。

对于关键技术取舍，使用最小实现、测试或 Benchmark 验证。

第四步：记录决策。

通过 ADR 说明选择理由、放弃的方案、已知限制和未来重新评估的条件。

第五步：开源实现。

公开可运行代码、测试、示例和必要的技术文档。

第六步：总结反馈。

根据测试、实际使用和社区反馈，持续修正设计。

这意味着技术文章和开源代码会相互支撑：

• 技术文章解释为什么这样设计。
• 开源代码展示实际如何实现。
• 自动化测试验证设计是否成立。
• 社区反馈帮助发现认知盲区。
• 后续文章记录方案如何演进。

十、总结：企业 Agent 的价值不只是更聪明

回到最初的问题：

通用 Agent 已经很强，企业为什么还需要自己的 Agent？

答案不是因为通用模型不够聪明，而是因为企业软件的价值不仅来自智能，还来自业务上下文、组织权限、数据治理、可靠执行和可验证的结果。

通用模型能够帮助系统理解“应该做什么”。

但企业仍然需要回答：

• 什么事件应该触发 Agent？
• 谁允许它执行？
• 它可以使用哪些数据？
• 它应该调用哪个业务系统？
• 多个 Agent 如何共享任务上下文？
• 外部操作成功与否如何判断？
• 失败后如何安全恢复？
• 哪些信息可以长期保存和共享？
• 谁对最终结果负责？

这些问题共同构成了企业级 Agent 工程的核心。

未来，随着通用模型和 Agent 平台继续发展，企业自研的边界也会变化。今天需要自己实现的基础能力，明天可能成为成熟平台的一部分。

因此，真正重要的不是坚持自研某个框架，而是理解问题、识别边界，并做出合理的技术选择。

本系列将以企业研发协作 Agent 为实践载体，从需求分析出发，逐步研究事件驱动架构、Agent Runtime、Multi-Agent、Memory、Context Engineering、MCP、可靠性、安全和评估体系。

我们的目标不是重新发明一个通用 Agent，而是探索如何让 Agent 成为企业研发体系中可信、可控、可维护的协作参与者。

参考资料

以下资料主要用于分析企业需求和架构方向。招聘信息具有时效性，厂商官方资料不等同于独立生产效果评测。

1. 滴滴招聘：AI Agent 基建平台架构师 — Agent 生命周期、编排、运行时与稳定性要求。
2. 京东招聘：Agent 平台方向 — Agent 平台与业务系统集成相关招聘资料。
3. Google Cloud：Introducing Gemini Enterprise Agent Platform — 企业 Agent 平台能力与治理方向。
4. Microsoft：Agent Identity — Agent 身份与授权管理。
5. AWS：Secure AI Agents with AgentCore Gateway — Agent 工具执行的策略与安全控制。
6. Salesforce Architects：The Agentic Enterprise — 企业 Agent 架构、语义层、编排与治理。
7. LangGraph 官方文档 — 有状态 Agent 工作流与运行时。
8. OpenAI Agents SDK 官方文档 — Agent、工具、交接与追踪。
9. Model Context Protocol 官方文档 — Agent 与外部工具、资源的标准化集成。
10. OWASP GenAI Security Project — 生成式 AI 与 Agent 安全风险。

下一篇：《Agent、Workflow 与 Multi-Agent：执行模型、适用边界与架构选型》

下一篇将从 Agent 的运行机制出发，比较确定性工作流、单 Agent Loop、多 Agent 协作和状态图执行模型，研究它们各自解决什么问题，以及什么时候不应该使用 Agent。