12 posts tagged with "开源"

2026 年 8 月 17 日，Agentic AI Foundation（AAIF）官方博客宣布：Agent2Agent（A2A）协议正式成为该基金会托管的第五个开源项目。至此，AAIF 的"开放智能体技术栈"五层拼图全部就位——从上下文、运行时、工具连接、流量管控到 Agent 间互操作，每个关键环节都有了中立治理的开源底座。

一、新闻背后："迟来却必然"的官宣​

A2A 加入 AAIF 的新闻，表面看是一次项目归属的变更，实质上是整个 Agent 生态从"百花齐放的发明期"走向"标准收敛的生产期"的标志性事件。

回顾时间线，这条路的每一步都有迹可循：

• 2025 年 4 月：Google 在 Cloud Next 上发布 A2A 协议，提出"Agent 之间如何发现、委派与协作"这一命题；
• 2025 年 6 月：Google 将 A2A 捐赠给 Linux Foundation，AWS、Cisco、Microsoft、Salesforce、SAP、ServiceNow 等成为创始组织；
• 2025 年 8 月：IBM 的 Agent Communication Protocol（ACP）正式并入 A2A，两大厂商标准走向合并，行业明确押注"单一共享标准"而非"多协议竞争"；
• 2025 年 12 月：Linux Foundation 宣布成立 AAIF，以 MCP、AGENTS.md、goose 为创始项目；
• 2026 年 3 月 12 日：A2A v1.0 正式发布，成为首个稳定版规范——新增多协议绑定、版本协商、多租户与签名 Agent Card，标志着协议从实验走向生产就绪；
• 2026 年 5 月：v1.0.1 补丁发布，修正 HTTP 绑定与 TaskStatus 规范；
• 2026 年 8 月 17 日：A2A 正式成为 AAIF 托管项目，补齐了技术栈最后一块拼图。

150+ 组织、超过 22,000 的 GitHub Star、三大公有云全面接入——A2A 用一年时间从"Google 的实验"长成了"生产级行业标准"。而入列 AAIF，则是给这套标准找到了一个"没有单一参与者能控制"的中立之家。

二、AAIF：为 Agent 生态造一个"中立之家"​

在展开五个项目之前，有必要先理解 AAIF 本身。

Agentic AI Foundation 于 2025 年 12 月由 Linux Foundation 发起，创始参与方包括 OpenAI、Anthropic、Block、AWS、Google、Microsoft、Bloomberg、Cloudflare 等。它的定位是：开放标准智能体 AI 技术栈的中立家园。

几个关键数据可以说明它的份量：

• 截至 2026 年 8 月 13 日，AAIF 成员总数已达 247 家，仅当季度就新增 57 家（3 家 Gold、33 家 Silver、21 家 Associate）；
• 新增 Gold 成员包括 阿里巴巴 和 Visa，支付、银行、供应链等合规敏感行业正在加速入场；
• 基金会发布的《Agentic AI Momentum Report》已跟踪 116 个开源项目，覆盖智能体技术栈的五个层次。

这里的核心逻辑，是 Linux Foundation 几十年验证过的模型：当基础设施组件被单一厂商持有，下游团队就要承受该厂商的路线图与发布节奏；当它被开放治理，社区才能决定"构建什么、何时构建"。 A2A 的 150+ 合作组织里包含大量直接竞争对手，这种广度只有在无人能单方面掌控的治理结构下才能维持。

三、核心主角：A2A 协议到底解决什么问题？​

3.1 痛点：集成成本不在 Agent 本身，而在 Agent 之间​

供应链与金融行业的工程师在把多智能体系统部署到生产时，反复遇到同一个问题：基于不同框架构建的 Agent 无法直接交接任务。每一次新增厂商关系，都要从零编写一份点对点的定制集成代码。真正的成本不是 Agent 本身，而是 Agent 之间的集成。

3.2 机制：Agent Card + JSON-RPC + Task 生命周期​

A2A 的解法是一套轻量、框架无关的通信契约：

• Agent Card（Agent 名片）：每个 Agent 发布一份结构化描述，声明"我能做什么、如何触达我"。其他 Agent 读取名片即可完成能力发现，无需人类居中牵线；
• JSON-RPC 2.0 over HTTP(S)：同步请求、SSE 流式、异步推送三种交互模式，支持长时任务与人机协作；
• Task 对象：标准化的任务生命周期跟踪，让协作过程结构化、可观测；
• Opaque Execution（不透明执行）：协作双方无需暴露内部思维链、执行计划或工具实现，只交换公共契约——Agent 是"不透明服务"，而非简单的工具集成。

这组设计让 A2A 与 MCP 形成清晰分工：MCP 解决"Agent 如何用工具"（纵向），A2A 解决"Agent 如何与 Agent 协作"（横向）。一个生产环境里往往两者并用：MCP Server 向单个 Agent 暴露工具，A2A 把多个 Agent 编组成系统。

3.3 生产实践：已经从 PPT 走到了操作系统​

A2A 的价值不止于规范，它已经在移动平台、云 AI 基础设施、金融、供应链和企业 IT 中大规模落地：

四、核心分析：AAIF 五个开源项目现状​

AAIF 的技术栈设计精妙之处在于——它不是五个无关项目的堆叠，而是对"一个 Agent 从思考到执行到协作"全过程的分层抽象。以下按技术栈自底向上逐层拆解。

4.1 第一层 · 指令与上下文：AGENTS.md​

• 定位：标准化项目如何向 AI Agent 传达期望、约定与操作指令。
• 一句话概括："给机器读的 README"。
• 现状要点：
  • 由 OpenAI 于 2025 年 8 月提出，现由 AAIF 托管；
  • 采用纯 Markdown、命名固定为 AGENTS.md、位于仓库根目录，规则极度简单——"简洁即是设计"；
  • 支持 monorepo 嵌套、closest-file-wins 解析，帮助 Agent 在有限的上下文窗口里快速找到高优先级信息；
  • 已被超过 6 万个开源项目采用，Claude Code、Cursor、GitHub Copilot、OpenAI Codex、Windsurf 等主流编码工具均原生支持或通过 symlink 读取。
• 生态观察：这是五层中"最轻"的一层，却承担了语境标准化的职能。当大量 LLM 工具各自发明配置文件格式（CLAUDE.md、.cursor/rules、copilot-instructions）时，AGENTS.md 正在成为那个"单一事实来源"（single source of truth）。有意思的是，研究也提醒：上下文文件并非越详细越好——不必要的约束反而会拉低 Agent 任务成功率、抬高推理成本。"最少必要指令"是这个标准的哲学。

4.2 第二层 · Agent 运行时：goose​

• 定位：Agent 推理、规划、调用能力、执行任务的运行环境。
• 一句话概括：Agent 的"身体"，承载思考与行动。
• 现状要点：
  • 由 Block 贡献的本地优先（local-first）Agent 运行时；
  • 是 AAIF 创始项目之一，也是 MCP Dev Summit 上重点教学的三项技术之一；
  • 与 agentgateway 有原生集成，可为其提供治理与控制能力。
• 生态观察：相比 MCP 和 A2A 的话题热度，goose 属于"闷声做事"的一层。它把"Agent 到底跑在哪个环境里"这个问题具体化——本地、容器、云上皆可。它和 agentgateway 的联动值得关注：运行时 + 网关，构成了"执行 + 治理"的闭环。

4.3 第三层 · Agent 到工具的连接：MCP​

• 定位：标准化 Agent 如何连接和交互工具、数据源、应用与服务。
• 一句话概括："给 AI 的一双手"，Agent 获取外部能力的标准通道。
• 现状要点：
  • 由 Anthropic 于 2024 年底提出，是 AAIF 三大创始项目之首；
  • 已形成围绕 MCP 的完整生态：MCP Server 暴露工具、MCP Client 消费工具；
  • AAIF 以 MCP 命名了旗舰会议品牌 MCPCon，2026 年全球活动（AGNTCon + MCPCon）覆盖北美、欧洲、亚洲、印度与非洲十余城；
  • 与 A2A 形成互补双协议：MCP 管"纵向"（Agent→工具），A2A 管"横向"（Agent→Agent）。
• 生态观察：MCP 是整个 AAIF 生态中采纳度最高、商业转化最成熟的一层。它定义了"工具"这个基本单元，几乎所有 Agent 框架和云平台都已兼容。某种意义上，MCP 是 AAIF 生态的"价值锚点"——其它四层都在围绕"Agent 获取能力、Agent 交付协作"这条主线展开。

4.4 第四层 · 流量中介与管控：agentgateway​

• 定位：位于 Agent 系统与其运行基础设施之间的边界，管理路由、策略与可观测性。
• 一句话概括：Agent 世界的"服务网格 + API 网关"。
• 现状要点：
  • 由 Solo.io 于 2025 年 3 月创建，2025 年 8 月 25 日捐赠 Linux Foundation，2026 年 6 月 4 日正式成为 AAIF 第四大托管项目（Growth 阶段）；
  • 统一数据面：单一 Rust 二进制同时处理 MCP、A2A、LLM 推理、HTTP、gRPC 流量——"三种合一"（LLM + MCP + A2A）；
  • 安全控制：JWT、API Key、RBAC、外部授权、mTLS、CORS，以及恶意工具行为防护；
  • 可观测性：面向 AI/Agent 工作流的指标、追踪、访问日志，可对接 SIEM；
  • 治理能力：CEL 声明式策略、限流、提示词护栏、预算控制、模型别名，MCP 虚拟化（多 MCP Server 联邦为单一接入点）；
  • 部署形态：裸机、VM、容器、Kubernetes 均可，完整兼容 Gateway API，支持 xDS 无中断热更新；
  • 社区规模：周下载量从约 10 万增长至 100 万+，总下载量突破 700 万；300+ 活跃贡献者，来自 60+ 组织（含 CoreWeave、Red Hat、Adobe、Salesforce、Microsoft 等）；
  • 已被 Istio 采纳为 AI 网关场景的数据面选项。
• 生态观察：这是五层中最具"基础设施"气质的项目，也是把传统云原生经验（服务网格、API 网关、零信任）迁移到 Agent 时代的关键桥梁。平台团队终于可以用熟悉的运维原语（安全、可观测、路由、治理、可靠性）管理 Agent 流量，而无需另起炉灶。agentgateway 的存在，让"Agent 流量"第一次获得了与 HTTP 流量同等的可治理性。

4.5 第五层 · Agent 间互操作：A2A​

• 定位：标准化独立 Agent 如何跨系统、跨组织边界相互发现、通信、委派任务与交换结果。
• 一句话概括："给 AI 的同事关系"，让不同厂商、不同框架的 Agent 能够对话。
• 现状要点：
  • 2026 年 8 月 17 日成为 AAIF 第五个托管项目，补上技术栈最后一块拼图；
  • 150+ 组织支持，技术指导委员会（TSC）覆盖 Google、Microsoft、AWS、Cisco、Salesforce、ServiceNow、SAP、IBM 八家厂商；
  • 2026 年 3 月 v1.0 稳定版：多协议绑定、版本协商、多租户、签名 Agent Card（密码学身份验证）；
  • 生产落地横跨移动 OS（华为 Celia）、超级 App（微信）、三大云（Google/Azure/AWS）、支付（AP2）；
  • 设计核心：Agent Card 发现 + JSON-RPC 交互 + Task 生命周期 + 不透明执行。
• 生态观察：A2A 是 AAIF 五层中"叙事天花板"最高的一层——它直接指向"Cisco 工程师所说的 Internet of Agents（Agent 互联网）"这一远景。当单个 Agent 的能力被 MCP 放大、被 goose 承载、被 AGENTS.md 规约、被 agentgateway 治理，最后真正让它们"成为社会"的，正是 A2A 这层互操作协议。

五、开源生态视角：五个项目，一个战略意图​

把五层放在一起看，AAIF 的布局逻辑非常清晰：

几点值得深挖的观察：

1. 五层恰好对应"人 + 工具 + 团队 + 治理"的软件工程隐喻。 AGENTS.md 是团队的"工作手册"，goose 是"执行者"，MCP 是"工具箱"，agentgateway 是"信息安全部 + 网关"，A2A 是"跨部门协作协议"。AAIF 实际上是在用三十年企业软件工程的经验，为 Agent 文明铺设基础设施。

2. 三大创始项目分属三家竞争巨头（OpenAI、Anthropic、Block），这本身就是中立治理的最大证明。 如果 AAIF 只是某一家厂商的"后花园"，这些项目根本不可能共存。它能同时容纳 OpenAI 的 AGENTS.md 与 Anthropic 的 MCP，说明"无人能控制"不是口号，而是生态得以成立的前提。

3. 时间线揭示了一个清晰的"标准收敛"规律。 2025 年是"多协议混战"：A2A 与 IBM ACP 竞争、各家自造配置文件。2026 年则是"单一标准收敛"：ACP 并入 A2A，AGENTS.md 统一配置格式，AAIF 成为共同归宿。历史经验表明，当标准涉及跨厂商协作时，市场最终会向"单一、开放、中立"收敛——就像当年 TCP/IP 和 HTTP 的结局。

4. 商业化路径已经隐现：协议层免费，基础设施层收费。 协议与规范（AGENTS.md、MCP、A2A）是开放的、中立的，它们负责"定义语言"；而真正产生商业价值的是运行它们的"基础设施"——agentgateway 的治理能力、云平台的原生托管、AP2 的支付授权。这与 Linux 生态"内核免费、企业发行版付费"的商业模式一脉相承。

5. 亚太力量正在上升。 阿里巴巴成为 AAIF 新 Gold 成员；华为将 A2A 落地为 OS 级标准、腾讯微信完成 A2A 对接；MCP Dev Summit 首站选在首尔。亚太厂商正在从"标准接受者"变成"标准共建者"——这对中国开发者既是机遇也是提醒：要参与标准、影响标准，而不是等待标准。

六、结语：Agent 的"HTTP 时刻"已到来​

A2A 加入 AAIF，宣告了 Agent 通信协议的"HTTP 时刻"：未来，Agent 之间能否对话，不再取决于它们由谁构建、用什么框架，而取决于它们是否遵守同一份开放契约。

对于开发者，这意味着两件事：

1. 学习曲线应聚焦"标准"而非"框架"。框架会过时，而 AGENTS.md、MCP、A2A 这类协议是跨代际的资产；
2. 选择基础设施时，优先考虑"中立治理"的项目。当你的系统依赖某个协议时，它不应该受制于任何单一厂商的产品决策——这正是 AAIF 存在的全部意义。

从上下文（AGENTS.md）到运行时（goose），从工具连接（MCP）到流量治理（agentgateway），再到 Agent 互操作（A2A）——五个开源项目拼出的，是一张完整的 Agent 时代"操作系统"蓝图。而这套系统最了不起的地方，在于它是开放的。

参考来源：AAIF 官方博客《A2A joins AAIF's open agentic stack》（2026-08-17）、Linux Foundation 官方新闻、agentgateway.dev、a2a-protocol.org、AAIF Momentum Report 等。

在 AI 编程普及的今天，GitHub Copilot、Cursor、OpenAI Codex等工具已经成为开发者的标配。当有新的贡献者带着 AI 编程工具来到你的开源项目时，AI 是会成为一个高效的高级工程师，还是一个到处制造混乱的“实习生”？ 答案往往取决于你是否为 AI 提供了明确的上下文。这就是 AGENTS.md 规范诞生的原因。

与此同时，越来越多的开发者在参与开源项目贡献时使用自己的AI Coding Agent，这包括向Linux内核提交代码。所以开源项目及其维护者不得不积极面对这一现实变化。

1. 什么是 AGENTS.md？​

简单来说：README.md 是写给人类看的，而 AGENTS.md 是专门写给 AI 编程工具看的。

它是一个放置在项目根目录下的标准 Markdown 文件（遵循 https://agents.md 开放规范），用于为 AI Agent 定义在当前仓库中工作的操作规范、架构约束、技术栈细节以及常用的终端命令。

2. 为什么要使用 AGENTS.md？​

在项目中引入 AGENTS.md 能带来立竿见影的收益：

消除“幻觉”与过度重构：AI 经常会根据其训练数据推荐过时的库，或者在修复小 Bug 时擅自重构不相关的文件。在 AGENTS.md 中设定严格的边界，可以大幅降低这类风险。

统一跨工具的行为：无论贡献者使用的是 Cursor、Copilot 还是独立的 CLI ，AGENTS.md 都能作为唯一的事实来源（Single Source of Truth），确保 AI 生成的代码符合你项目的风格指南。

大幅降低新贡献者的上手门槛：当开发者启动 AI 助手时，AI 会自动读取该文件，了解如何构建项目、运行测试和格式化代码，无需开发者反复手动向 AI 投喂冗长的上下文。

提升测试与交付的成功率：通过提供精确的测试和校验命令，你可以要求 AI 在修改代码后自行验证结果。

3. 如何编写高质量的 AGENTS.md？​

编写给 AI 看的文档，与写给人类看的文档有本质区别。AI 不需要客套话，需要的是可执行的命令和明确的规则。

第一步：在根目录创建文件 直接在仓库根目录新建 AGENTS.md ，并在头部明确其用途和角色设定。如果是一个大型单仓项目，那么你也可以在不同模块下创建专属于该模块的 AGENTS.md ，这完全没有问题，符合最佳实践。

第二步：指令命令化 (Command-First) 不要使用模糊的散文。例如，不要写“请确保代码通过测试”，而是直接提供命令，让 AI 可以通过退出码 (Exit Code) 来验证结果：

“在完成任何修改后，必须运行 npm run test 和 npm run lint。”

第三步：明确技术栈与代码规范 指出项目使用的具体库版本和约定俗成的写法，明确禁止 AI 引入你不想要的技术栈。

第四步：划定红线（边界） 明确告诉 AI 哪些目录是只读的，哪些文件是自动生成的、绝对不能手动修改的。

真实案例模板 以下是一个适用于前端项目的 AGENTS.md 示例，展示了如何清晰地向 AI 下达指令：

## AI 编程操作指南
你是一个资深的前端工程师。在修改本仓库的代码前，请严格遵循以下规则：

### 1. 技术栈与架构
-  这是一个使用 React 18 + TypeScript + Vite 的项目。
-  状态管理使用 Zustand，**请勿引入 Redux** 。
-  样式使用 Tailwind CSS。**禁止编写内联样式**  (`style={{...}}`)。

### 2. 编码规范
- 优先使用 `const`  而不是 `let` 。
- 在定义类型时，优先使用 `interface`  而不是  `type` 。
- 组件必须放置在 `src/components/`  目录下，并使用命名导出（Named Exports）。

### 3. 测试与验证
在完成任何代码修改后，你必须在终端执行以下命令验证更改：
- 运行测试： `npm run test`
- 类型检查： `npm run typecheck`
- 代码格式化： `npm run lint:fix`

### 4. 边界与限制
- **绝对不要**  修改 `src/legacy/` 目录下的任何文件，该目录已被标记为废弃。
-  不要尝试手动修改 `package-lock.json`。

当然，对于相对比较简单的项目，你完全可以尝试让Coding Agent在阅读了 AGENTS.md 官网的信息后自动帮你快速创建一个 AGENTS.md 文档，在经过你的评审后即可使用。

4. 结语​

在 AI 原生开发的浪潮中，让 AI 更好地理解你的项目，是维护代码质量和提升社区协作效率的关键。在你的开源项目中花几分钟添加一个 AGENTS.md，你将收获更高质量的 Pull Request 和更少的人工评审负担。

立刻行动起来，为你的代码库雇佣一个合格的“AI 守门人”吧！

相关链接​

• AGENTS.md https://agents.md/
• AAIF https://aaif.io/

OSPO 介绍 漫画版​

此前发布过的【OSPO 漫画：来自日本OSPO Summit 2023的分享】，近期终于抽时间完成了中文版翻译。原作品使用日语和英语发布在 https://www.miraclelinux.com/miracle110/miracle-chan 及X平台，使用CC BY-SA 4.0许可；中文版是基于英语版本翻译而来，已和原作沟通，后续也会同步发布到X平台。

OSPO = Open Source Program Office，即 开源项目办公室，也称为开源办公室。​

生成式AI在持续快速发展进化，OSI 也在持续推动行业共识，研讨“开源人工智能”的定义，笔者一直在跟进该项工作的进展，近期看到OSI官方博文发布了最新的v0.0.7版本，特此翻译供参考。（OSI官网内容采用知识共享 署名 4.0 国际许可协议）

HackMD上发布的 OSAI v0.0.7，欢迎参与反馈和讨论。 https://hackmd.io/@opensourceinitiative/osaid-0-0-7

OSI官方博客文章链接 https://opensource.org/blog/open-source-ai-definition-weekly-update-april-15

OSI官方论坛的讨论帖，欢迎反馈意见与建议。 https://discuss.opensource.org/t/draft-v-0-0-7-of-the-open-source-ai-definition-is-available-for-comments/298

缩略语与术语​

• AI 人工智能 或 人工智能系统
• OSAI 开源人工智能
• Gen AI 生成式人工智能
• OSI 开放源代码促进会，是一个国际的开源促进组织，官网 https://opensource.org/，开源定义就由其组织完成，并发布了经其认证的开源许可清单。
• Data card “数据卡”，结合中文语境和使用习惯，下文使用了“数据信息看板”
• Model card “模型卡”，结合中文语境和使用习惯，下文使用了“模型信息看板”

开源 AI 定义​

版本 0.0.7.1

注：本文件由三部分组成：前言说明了本文件的意图、开源人工智能定义本身以及评估法律文件的核对表。

本文件采用了经济合作与发展组织（OECD）对人工智能系统的定义（https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0449）。

人工智能系统是一种以机器为基础，可以根据明确或隐含的目标，从接收到的输入信息中推断出如何生成预测、内容、建议或决策等输出结果，从而影响物理或虚拟环境的系统。不同的人工智能系统在部署后的自主性和适应性程度各不相同。

关于人工智能系统定义的更多信息，请访问 OSI 博客（https://blog.opensource.org/open-source-ai-establishing-a-common-ground/）。

原文标题：3 types of leadership for open organizations Servant leaders, quiet leaders, and open leaders have traits useful to open organizations.

原文链接：https://opensource.com/article/23/2/leadership-open-organizations

作者 Len Dimaggio 发表于 2023-2-9

在经典电影《佳人有约》中，一个犯罪团伙的头目打嗓门儿威胁式地反复吼道："照我说的做！"以此展示他的领导风格。这在喜剧中很有娱乐性，但在一个开放式组织中，这样做会导致失败和被忽视。

在本文中，我将回顾在开放式组织中有效的领导风格。请记住，这些领导风格并非存在于真空或孤岛之中。要想成为一名有效的管理者，你需要根据具体情况的要求，组合使用各种领导风格技巧。

这三种领导风格对开放型组织很有帮助。

服务型领导 Servant leadership​

俗话说，政客想要当选，要么成人要么成事。这句谚语也适用于任何类型的领导人。有些领导人只想当指挥；虽然所有领导人都有野心，但对这类领导人来说，满足自己的野心才是首要目标，获得权力本身就是目的；一旦拥有权力，他们可能就无心利用权力来解决问题或建功立业。组织取得的任何成就对他们来说都像是个人的胜利。

相比之下，如果你是一名服务型领导者，你就会把自己的领导角色看作是为人民服务的一种手段。在政界，你会把公共服务看作是帮助公众的机会，而不是陈词滥调。作为一名服务型领导者，你会努力改善所领导的人的生活，并主要关注周围人的福祉。

服务型领导还很有感染力。通过关注你所领导的人的福利和发展，你正在培养下一代服务型领导。作为服务型领导者，你不喜欢独揽功劳。例如，当传奇棒球经理凯西·斯坦格尔（Casey Stengel）因赢得联赛冠军而受到祝贺时，他说了一句著名的话："没有我的球员，我不可能做到这一点。”作为一名经理，他最伟大的技能之一就是最大限度地发挥每个球员的贡献，使整个球队受益。

沉稳型领导 Quiet leadership​

过去几年，我们一直生活在名人CEO的时代。他们很容易识别：他们粗鲁、高调，不断宣传自己，好像他们知道所有问题的答案。他们试图主宰每一次互动，希望成为众人瞩目的焦点，并经常通过告诉别人该怎么做来发挥领导作用。爱丽丝·罗斯福·朗沃思（Alice Roosevelt Longworth）形容她的父亲、美国总统西奥多·罗斯福（Theodore Roosevelt）是一个“每次葬礼都想当尸体，每次婚礼都想当新娘，每次洗礼都想当婴儿”的人。罗斯福是一位卓有成效的领导者，他做了很多非凡的事情，比如创办美国国家公园管理局和修建巴拿马运河，但他并不沉默寡言。

相比之下，当你是一个沉稳型领导者时，你会以身作则。你不会纠结于问题，而是保持积极的态度，让行动说话。你专注于可以做到的事情。你通过解决问题和为团队树立榜样来发挥领导作用。面对突如其来的问题，沉稳型领导者不会把时间花在抱怨上，而是寻找解决方案并付诸实施。

开放型领导 Open leadership​

作为服务型领导者，你要努力帮助组织成员成长为领导者。沉稳型领导者以身作则。服务型领导者和沉稳型领导者不会独断专行。开放型领导者兼具上述诸多特点。

开放型领导者也不是自上而下的专制领导者。作为一名开放型领导者，你的成功之道在于创建能够让团队茁壮成长的组织。换句话说，作为一名开放型领导者，根据《开放型组织定义》，你要创建一个框架或环境，让组织能够实现以下目标：

• 更加敏捷：在开放式组织中，所有团队成员都清楚地了解组织的目标，因此可以更好地协同工作，实现这些目标。

• 更快创新：在开放式组织中，无论想法来自何处，都会被听取（评审和争论）。领导者不会把想法强加给组织。

• 更高参与度：由于组织成员可以参与组织方向的决策，因此他们对团队的目标有一种主人翁意识。

开放式组织将以下五大特征定义为开放式组织的基本原则：

• 透明性：组织的决策过程是开放的，所有支持项目的资源也是开放的。团队从不对孤立做出的决定感到惊讶。
• 包容性：所有团队成员都参与讨论和评审。制定规则和协议，确保所有观点都得到评审和尊重。
• 适应性：不断要求并接受反馈意见。团队根据结果和投入不断调整未来的行动。
• 协作性：团队成员从项目或任务一开始就一起工作。工作不是孤立地或各自为政地进行，然后再提交给团队其他成员征求意见。
• 社区性：团队成员对组织如何运作有共同的价值观。团队领导以身作则，鼓励所有团队成员为团队做出贡献。

发挥领导风格的作用​

作为一名开放型领导者，你如何才能兼具服务型领导和沉稳型领导的特点？

在开放式组织中，为了支持一个包容的社区，你要发挥导师的作用。正如服务型领导者会教导和培养未来的服务型领导者一样，你也必须身体力行，以身作则，确保透明度和协作性，并按照共同的价值观行事。

沉稳型领导者如何为开放型组织做出贡献？开放式组织往往很嘈杂，没有更好的词来形容。开放式组织中的交流与合作是持续不断的，有时会让不习惯这种交流与合作的人不知所措。开放式组织成员的主人翁意识可能导致争论不休、激情四射的讨论和分歧。

沉默寡言、积极乐观的领导者往往能从看似矛盾的观点中看到前进的道路。在这些讨论中，沉稳型领导者能够打破喧嚣。而作为开放式组织的镇定剂，安静型领导者可以帮助人们克服分歧，同时推动问题的解决。