背景设定

• 原始环境：Intel 架构 Mac，pyenv 管理多 Python 版本，环境优雅。
• 迁移：macOS 系统迁移工具一键搬家到 Apple Silicon (M4) 新机，所有配置、隐藏目录、工具链一锅端。
• 新问题：Cursor（AI code editor，VS Code 衍生）Python 插件死活卡在“Discovering Python Interpreters”，开发体验极差。

1. 初步尝试：极客的直觉

• 直接用 uv 创建虚拟环境 .venv，命令行下激活、pip、python 一切正常。
• 但 Cursor GUI 里 Python 插件一直在“Discovering Python Interpreters”，无法流畅选择虚拟环境。
• 卸载 Python 插件后问题消失，重装后复现，直觉告诉我——插件在解释器发现阶段掉坑了。

2. AI 介入：协作 Debug 启动

Step 1：AI 先问清需求

AI：你想用 uv 还是标准 venv？
我：uv，极客当然要用新玩意。

Step 2：AI 自动帮我用 uv 创建 .venv

AI：虚拟环境已建好，激活即可。
我：source .venv/bin/activate，OK。

Step 3：AI 贴心提示

AI：如果 GUI 还在“Discovering”，可以手动选解释器、检查 Python 插件、重启 Cursor、设置 .vscode/settings.json，还可以看 Output 日志。

Step 4：我反馈

我：都试了，还是卡住，Cursor 里就是“Discovering Python Interpreters”。

Step 5：AI 继续排查

AI：请问你用的什么编辑器？
我：Cursor。

AI：那你可以试试：

• 手动选 .venv/bin/python
• 检查 Python 插件日志
• 检查 .vscode/settings.json
• 检查系统里有无多余 Python 版本
• 甚至用标准 venv 测试兼容性

3. 进入极客 Debug 模式

Step 6：AI 自查环境

AI：让我自查下你的 .venv 结构和 Python 路径。

• .venv/bin/python → /opt/homebrew/opt/python@3.13/bin/python3.13
• Python 3.13.3，虚拟环境结构标准
• which python/which python3 都指向 .venv

AI 结论：你的虚拟环境没毛病，问题在于 Cursor 的 Python 插件解释器发现机制。

4. 深入 Output 日志，真相渐现

Step 7：AI 指导我贴 Output 日志

我：贴了 Output 日志，里面有一堆解释器扫描和报错。

Step 8：AI 逐行分析日志

• 插件扫描到 .venv/bin/python，能正确识别 3.13.3
• 但也扫描到 ~/.pyenv/versions/3.10.15/bin/python，报错缺 libintl.8.dylib
• 这是 pyenv 在 Intel Mac 上装的 Python 3.10.15，迁移到 M4 后架构/依赖不兼容
• 插件在解释器发现阶段被 pyenv 的遗留目录拖慢甚至卡死

AI 结论：问题根源是 pyenv 的历史遗留目录，Cursor 插件扫描解释器时遇到报错，导致“Discovering”卡住。

5. 极客式解决方案

Step 9：我问能否用 uv 删除 pyenv 解释器

AI：uv 只管虚拟环境，不管全局 Python 版本。你可以直接 rm -rf ~/.pyenv/versions/3.10.15，一刀切。

Step 10：我执行删除

• 直接 rm -rf ~/.pyenv/versions/3.10.15
• 重启 Cursor，问题消失，插件秒识别 .venv，开发体验恢复丝滑

6. 终极总结：人与 AI 协作 Debug 的极客范本

过程回顾

• AI 不是简单给出答案，而是每一步都在引导、验证、分析，和我一起排查所有可能性。
• 从环境自查、插件配置、日志分析，到最终定位 pyenv 遗留目录，AI 全程参与，极大提升了排查效率。
• 过程中我也不断反馈实际操作和现象，AI 根据新信息动态调整建议，真正实现了“人机协作 Debug”。

极客经验

1. 系统迁移后，历史遗留目录是大坑
   pyenv/conda 这类多版本管理工具，目录残留会让 IDE 插件掉坑。
2. IDE 插件解释器发现机制很“贪心”
   只要目录在，就会递归扫描，哪怕解释器不可用也会报错拖慢。
3. 日志是极客 Debug 的第一生产力
   Output 日志能直接暴露问题根源，别怕信息量大，逐行分析总能找到线索。
4. AI 是极客的最佳 Debug 伙伴
   能自动化环境自查、日志分析、方案建议，极大提升排查效率和体验。
5. 大胆 rm -rf，极客的魄力
   明确问题根源后，果断清理历史遗留，环境即刻清爽。

结语

这次 Debug 之旅，是人与 AI 协作的极客范本。
AI 不只是工具，更是并肩作战的 Debug 伙伴。
希望这份记录能帮到所有在环境迁移、工具兼容、IDE 插件卡死等问题中挣扎的极客们。

Debug，不止于人，更在于协作。

本笔记记录了近期对 AIGC、AGI 与 Agent 等前沿 AI 技术的探索与实践心得，旨在梳理各技术概念、分析核心实现以及展望未来趋势。

目录

1. AIGC 与 AGI 趋势
2. Agent 技术详解
   • 2.1 Agent 定义与核心能力
   • 2.2 Agent 底层依赖与行动实现
3. LLMs Text 说明
4. MCP 标准与生态
   • 4.1 MCP 原理
   • 4.2 MCP Client 与 Server
5. Multiple-Agents 多智能体
6. 术语解释与参考资料

AIGC 与 AGI 趋势

近年来，AIGC（AI Generated Content）技术迅速发展，已从文本、图片生成扩展到音视频内容，并不断拓宽应用领域。AIGC 的未来正逐步向 AGI（Artificial General Intelligence）迈进。

主要趋势：

• 生态演进
  由传统问答和内容生成转向注重自主决策的 Agent 及其多智能体生态系统。

• 系统能力升级
  强调从单一生成到具备感知、推理、行动和反馈的综合能力，实现更动态的交互。

• 应用场景扩展
  应用从内容创作延伸至自动化运维、智能客服及企业知识管理，实现跨领域协同工作。

Agent 技术详解

Agent 定义与核心能力

Agent 是能代表用户独立完成任务的智能系统。不同机构对其定义有所不同：

• OpenAI 的观点：
  “Agent 是能独立代表你完成任务的技术系统”，重点在于其自主执行的能力。

• Anthropic 的解读：
  强调将动态自主决策与预设工作流分离，认为部分 Agent 适用于复杂任务管理，而其他则更适合预设流程的执行。

核心能力包括：

• 感知： 理解用户输入、外部环境及多模态信息。
• 推理： 分析任务需求，拆分为多个子任务并设计解决方案（例如采用 ReAct 框架）。
• 行动： 调用外部 API 或工具，实现任务执行。
• 反馈与自我调整： 根据任务执行情况不断调整策略，保持最佳状态。

Agent 底层依赖与行动实现

底层依赖——LLMs Text：

• 信息获取和结构化处理：
  通过对原始网页内容进行提炼，降低信息噪声，确保 Agent 针对关键数据作出决策。

优势：

• 高效解析： 减少原始数据中冗余信息，减轻上下文负担。
• 精准索引： 便于后续检索及数据整合，提升响应速度。

开发选择：

• Agent Framework： 利用明确的逻辑循环与状态管理实现任务调度。
• Agent SDK： 提供抽象化接口，开发者关注业务逻辑而不必处理底层细节。

行动实现方式：

• Function Calling：
  例如 GPT-4.1 支持在推理过程中调用预定义函数，自动生成调用请求并整合返回结果。

• MCP 协议应用：
  通过详细 API Schema 描述，构建标准化调用请求，并支持多种通信方式（如 SEE、stdio、HTTP 流）。

LLMs Text 说明

LLMs Text 标准将网页或文档内容提炼为结构化摘要，主要用于：

• 降低噪音： 提取核心数据，减少无关信息。
• 高效索引： 便于大语言模型快速定位并理解关键信息。

常见应用：

• 新闻聚合
• 企业知识库构建
• 智能客服系统

MCP 标准与生态

MCP 原理

MCP（Model Content Protocol）旨在规范大语言模型与外部 API 之间的数据交换，核心思想包括：

• API Schema 装饰：
  为每个 API 提供详细 schema 描述，包括功能、参数与返回数据格式。

• 自动调用生成：
  根据自然语言描述自动构造符合标准的 API 调用请求。

• 多样通信渠道：
  支持 Server-Sent Events（SEE）、stdio 及 HTTP 流等传输方式。

MCP Client 与 Server

• MCP Client：
  封装 API 调用逻辑，根据标准生成调用请求，目前已有工具如 Claude、Cherry Studio 支持。

• MCP Server：
  提供可供 Agent 调用的 API 接口，需要保证高可用性与实时响应，适用于多种企业场景。

Multiple-Agents 多智能体

Multiple-Agents 系统探索如何让多个 Agent 协同完成复杂任务，核心理念包括：

• 分工协作：
  不同 Agent 根据各自优势负责不同任务模块，如数据收集、策略制定与执行反馈。

• 通信机制：
  建立高效信息传递通道（例如消息队列、共享内存或分布式事件驱动）确保实时状态同步。

• 调度与协调：
  指定主控 Agent 或调度器统一分配任务，整合各 Agent 反馈。

• 技术框架：
  例如 OpenAI 的 openai-agents-python 框架，为多智能体协同提供开发工具与接口。

术语解释与参考资料

术语解释：

• AIGC： AI Generated Content，通过 AI 模型生成的各类内容。
• AGI： Artificial General Intelligence，旨在实现跨领域自主决策的通用智能。
• LLM： Large Language Model，为当前 AI 关键技术之一。
• Agent： 具备感知、推理与执行能力、能够独立或协同完成任务的智能系统。
• MCP： 模型内容协议，规范 LLM 与外部工具之间的数据交换。
• ReAct： 结合推理与行动，强调在决策中动态调用外部工具的框架。
• SEE： Server-Sent Events，实时向客户端推送数据的传输技术。

参考资料：

• MCP 官方文档
• ReAct 论文
• LLMs Text 标准
• 多智能体系统综述

备注：
本文内容仍在持续更新中，后续将补充更多案例分析、前沿技术动态及实践心得。 ```

乌克兰战争是一场持续了近2年的冲突，造成了数万人的死亡和伤残，以及数百万人的流离失所。这场战争不仅是乌克兰国内的政治危机，也是俄罗斯和西方国家之间的地缘政治角力。在这场战争中，平民是最大的受害者，他们不仅遭受了战火的摧残，也承受了社会经济的崩溃，人权的践踏，以及心理的创伤。这场战争让我们不得不思考一些深刻的问题：人类生存的意义是什么？人性的弱点是什么？为什么少数人的恶劣行为可以轻易地给他人带来灾难？我们又该如何避免这种人类悲剧的重演？

人类生存的意义

人类生存的意义是一个哲学上的永恒话题，不同的人有不同的答案。有些人认为生存本身就是意义，只要活着就有希望；有些人认为生存需要有目标，只有实现自己的价值才有意义；有些人认为生存需要有信仰，只有信奉某种理念或神灵才有意义。无论如何，生存对于每个人都是最基本和最重要的权利，没有人有权剥夺他人的生存权。然而，在乌克兰战争中，我们看到了多少无辜的生命被夺走，多少家庭被分离，多少梦想被破灭。这些平民没有参与战争，没有挑起冲突，没有威胁任何一方的利益，他们只是想过正常和平的生活。但是，他们却成了战争的牺牲品，他们的生存意义被无视，他们的生存权利被践踏。

人性的弱点

人性的弱点是一个心理上的普遍现象，每个人都有或多或少的缺陷。有些人贪婪自私，只顾自己的利益；有些人傲慢偏执，不听取他人的意见；有些人暴力残忍，对他人施加伤害；有些人愚昧无知，不愿接受新知识。这些弱点会导致人与人之间的冲突和矛盾，甚至会引发战争和灾难。在乌克兰战争中，我们看到了多少恶劣的行为造成了无法挽回的后果。比如，俄罗斯对乌克兰领土和主权的侵犯，导致了乌克兰东部地区的分裂和动荡；比如，乌克兰政府对反对派和少数民族的镇压和歧视，导致了乌克兰西部地区的抗议和暴力；比如，西方国家对乌克兰战争的干预和制裁，导致了乌克兰经济和社会的衰退和困境。这些行为都反映了一些人或一些集团在面对危机时表现出来的贪婪、傲慢、暴力和愚昧，他们没有考虑到他人的感受和利益，也没有考虑到长远的后果，他们只是为了满足自己的利益或信仰，不惜牺牲他人的生命和幸福。

避免悲剧的办法

我们该如何避免这种人类悲剧的重演？这是一个复杂而艰难的问题，没有简单而唯一的答案。但是，我们可以从以下几个方面尝试着寻找一些可能的解决办法。首先，从政治体制方面，我们需要建立一个更加民主和公正的国际秩序，让每个国家和每个人都能享有平等和尊重，让每个国家和每个人都能参与和影响国际事务的决策，让每个国家和每个人都能承担和分担国际事务的责任。其次，从教育方面，我们需要培养一个更加开放和包容的世界观，让每个人都能接受多元和全面的知识，让每个人都能理解和尊重不同的文化和价值，让每个人都能沟通和合作解决共同的问题。最后，从科技方面，我们需要发展一个更加先进和人性化的技术系统，让每个人都能享受科技带来的便利和福利，让每个人都能控制和管理科技带来的风险和挑战，让每个人都能创新和改善科技带来的影响和变化。

总之，乌克兰战争对平民带来了无妄之灾，也给我们提出了一些深刻的问题。我们需要反思人类生存的意义，认识人性的弱点，寻求避免悲剧的办法。我们希望这场战争能够早日结束，我们也希望这样的战争不要再发生。

2018-07-11 10:57:55

1397

收藏 一个正确配置的 HTTPS 网站应该在证书中包含完整的证书链。 比如以 openssl s_client-connect x.x.x.x:443

命令来查看 自己的网站配置。 其余内容可以无视，只看 Certificate chain 这一段： — Certificate chain 0s:/1.3.6.1.4.1.311.60.2.1.3=CN/1.3.6.1.4.1.311.60.2.1.2=Guangdong/1.3.6.1.4.1.311.60.2.1.1=Shenzhen/businessCategory=PrivateOrganization/serialNumber=440301103308619/C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE6\xB7\xB1\xE5\x9C\xB3\xE5\xB8\x82/postalCode=518067/street=\xE6\xB7\xB1\xE5\x9C\xB3\xE5\xB8\x82\xE5\x8D\x97\xE5\xB1\xB1\xE5\x8C\xBA\xE5\x8D\x97\xE6\xB5\xB7\xE5\xA4\xA7\xE9\x81\x931057\xE5\x8F\xB7\xE7\xA7\x91\xE6\x8A\x80\xE5\xA4\xA7\xE5\x8E\xA6\xE4\xBA\x8C\xE6\x9C\x9FA\xE6\xA0\x8B502#/O=WoSign\xE6\xB2\x83\xE9\x80\x9A\xE7\x94\xB5\xE5\xAD\x90\xE8\xAE\xA4\xE8\xAF\x81\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/CN= www.wosign.com i:/C=CN/O=WoSign CALimited/CN=WoSign Class 4 EV Server CA 1 s:/C=CN/O=WoSign CA Limited/CN=WoSignClass 4 EV Server CA i:/C=CN/O=WoSign CALimited/CN=Certification Authority ofWoSign 2 s:/C=CN/O=WoSign CALimited/CN=Certification Authority of WoSign i:/C=IL/O=StartComLtd./OU=Secure Digital CertificateSigning/CN=StartComCertification Authority — 其中 0 、 1 、 2 是证书链中每一级证书的序号。 0 是要被验证的网站所用的证书。其 CN 应该对应网站域名。 每一个序号后面， s 开头的一行是指证书， i 开头的一行是指此证书由谁签发。 0 的 CN 包含一个疑似中文域名，加一个英文域名 www.wosign.com 。它的签发者是 WoSign CA Limited/CN=WoSign Class 4 EV ServerCA 。 1 的证书就是 0 的签发者。而 1 自己又是由另一个证书 Certification Authority ofWoSign 签发的。 再看下一级， 2 。它说， CertificationAuthority ofWoSign 是由 StartCom 签发的 所以这么一级级看下来，浏览器说，哦， 2 的签发者我认识啊，安装包里有提到， StartCom 嘛。签名正确、验证无误，所以信任 2 。那么也应该信任 2 签发的 1 、 1 签发的 0 。所以这个网站可以信任。

－－

然而，如果网站配置时，在 crt 文件中只包含了自己，而没包含一个完整到可以被浏览器内置数据验证的证书链，就有可能被浏览器拒绝。比如 openssl s_client -connecttouko.moe:443 — Certificate chain 0 s:/CN=touko.moe i:/C=CN/O=WoSign CALimited/CN=WoSign CA Free SSL CertificateG2 — 只有 0 一组。说明 s 行中的 touko.moe 由 i 行中的 WoSign CA Free SSL CertificateG2 签发。没了。 这就是此坑最神奇之处：浏览器此时是否验证失败，是不一定的。有 2 种情况： A 、浏览器自安装以来，从未见过这个 i 。那么验证会失败。 B 、浏览器以前见过、并且验证过 i ，那么验证会成功。

通常管理员自己会去证书发行商的 https 网站买证书，浏览器就会验证，然后将验证成功的中间证书全都缓存下来，为以后节省时间。当管理员（错误地）配置完自己的网站，去浏览测试的时候，完全不会遇到问题。因为他的浏览器已经认识这个中间证书了。 https://csr.chinassl.net/ 这个网站可以申请免费的证书，以及可以检测外网证书链的完整性 ##yau 一般windows下的浏览器会自动帮你下载中间证书，但在移动端或其他终端则不一定，因此部署证书最好把中间证书都补上，特别是私网环境是必须的。 如果在Apache中配置证书时，是有 certificate chain 这个属性来指定中间证书的。 Nginx没有Certificat Chain这个参数，如果有中间证书，需要把域名证书和中间证书合并，然后指定给ssl_certificate才行。 重要的事情再说一遍， 用Nginx配置https证书，如果有中间证书，一定要和域名证书合并, 再指定给ssl_certificate。 合并要求用户证书在前面，中间证书（boundle）在后面。 参考： https://www.jianshu.com/p/8d525696ce86

的服务器上。 intermediates：CA用来认证公钥持有者身份的证书，即确认https使用的end-user证书是属于 qiniu.com 的证书。 root：用来认证intermediates证书是合法证书的证书。 简单来说，end-user证书上面几级证书都是为了保证end-user证书未被篡改，保证是CA签发的合法证书，进而保证end-user证书中的公钥未被篡改。我们使用end-user certificates来确保加密传输数据的公钥(public key)不被篡改，而又如何确保end-user certificates的合法性呢？这个认证过程跟公钥的认证过程类似，首先获取颁布end-user certificates的CA的证书，然后验证end-user certificates的signature。一般来说，root CAs不会直接颁布end-user certificates的，而是授权给多个二级CA，而二级CA又可以授权给多个三级CA，这些中间的CA就是intermediates CAs，它们才会颁布end-user certificates。 七牛云证书管理，会在用户上传证书的时检测证书的完整性，证书链不完整会自动帮用户补全证书链，但无法保证补全的证书链100%是正确的。所以需要用户选择使用自传的证书还是系统补全后的证书。 来自

https://developer.qiniu.com/fusion/kb/3703/the-certificate-chain-is-what 证书链检测和修复：

https://www.kkssl.com/ssltools/sslchain 查看域名的证书链： openssl s_client -connect www.xxx.com:443 -showcerts >/dev ull < < < “” 查看证书信息： openssl x509 -noout -text -in /data/bkee/cert/bk_domain.crt

作者：才云科技 李昂

评论(2) 作者：李昂 曾经就职于七牛， 参与七牛大数据产品的开发工作 加入才云科技后，主要负责 Devops 的相关工作 才云科技云平台容器工程师 今天给到大家介绍一下 Client-go 中的一个非常关键的工具包 Informer 。 Informer 内部实现极其复杂，详细介绍的文章也很少，很多人反馈比较难用。但不得不承认它也是一个设计精良、安全可靠的组件，值得我们去一探究竟。 Informer 简介 Informer 基础功能 Informer 是 Client-go 中的一个核心工具包。在 Kubernetes 源码中，如果 Kubernetes 的某个组件，需要 List/Get Kubernetes 中的 Object，在绝大多 数情况下，会直接使用 Informer 实例中的 Lister()方法（该方法包含 了 Get 和 List 方法），而很少直接请求 Kubernetes API。Informer 最基本 的功能就是 List/Get Kubernetes 中的 Object。 如下图所示，仅需要十行左右的代码就能实现对 Pod 的 List 和 Get。 Informer 高级功能 Client-go 的首要目标是满足 Kubernetes 的自身需求。Informer 作为其中的核心工具包，面对 Kubernetes 极为复杂业务逻辑，如果仅实现 List/Get 功能，根本无法满足 Kubernetes 自身需求。因此，Informer 被设计为一个灵活而复杂的工具包，除 List/Get Object 外，Informer 还可以监听事件并触发回调函数等，以实现更加复杂的业务逻辑。 Informer 设计思路 Informer 设计中的关键点 为了让 Client-go 更快地返回 List/Get 请求的结果、减少对 Kubenetes API 的直接调用，Informer 被设计实现为一个依赖 Kubernetes List/Watch API 、可监听事件并触发回调函数的二级缓存工具包。 更快地返回 List/Get 请求，减少对 Kubenetes API 的直接调用 使用 Informer 实例的 Lister() 方法， List/Get Kubernetes 中的 Object 时，Informer 不会去请求 Kubernetes API，而是直接查找缓存在本地内存中的数据(这份数据由 Informer 自己维护)。通过这种方式，Informer 既可以更快地返回结果，又能减少对 Kubernetes API 的直接调用。 依赖 Kubernetes List/Watch API Informer 只会调用 Kubernetes List 和 Watch 两种类型的 API。Informer 在初始化的时，先调用 Kubernetes List API 获得某种 resource 的全部 Object，缓存在内存中; 然后，调用 Watch API 去 watch 这种 resource，去维护这份缓存; 最后，Informer 就不再调用 Kubernetes 的任何 API。 用 List/Watch 去维护缓存、保持一致性是非常典型的做法，但令人费解的是，Informer 只在初始化时调用一次 List API，之后完全依赖 Watch API 去维护缓存，没有任何 resync 机制。 笔者在阅读 Informer 代码时候，对这种做法十分不解。按照多数人思路，通过 resync 机制，重新 List 一遍 resource 下的所有 Object，可以更好的保证 Informer 缓存和 Kubernetes 中数据的一致性。 咨询过 Google 内部 Kubernetes 开发人员之后，得到的回复是: 在 Informer 设计之初，确实存在一个 relist 无法去执 resync 操作， 但后来被取消了。原因是现有的这种 List/Watch 机制，完全能够保证永远不会漏掉任何事件，因此完全没有必要再添加 relist 方法去 resync informer 的缓存。这种做法也说明了 Kubernetes 完全信任 etcd。 可监听事件并触发回调函数 Informer 通过 Kubernetes Watch API 监听某种 resource 下的所有事件。而且，Informer 可以添加自定义的回调函数，这个回调函数实例(即 ResourceEventHandler 实例)只需实现 OnAdd(obj interface{}) OnUpdate(oldObj, newObj interface{}) 和 OnDelete(obj interface{}) 三个方法，这三个方法分别对应 informer 监听到创建、更新和删除这三种事件类型。 在 Controller 的设计实现中，会经常用到 informer 的这个功能。 Controller 相关文章请见此文《 如何用 client-go 拓展 Kubernetes 的 API 》。 二级缓存 二级缓存属于 Informer 的底层缓存机制，这两级缓存分别是 DeltaFIFO 和 LocalStore。 这两级缓存的用途各不相同。DeltaFIFO 用来存储 Watch API 返回的各种事件 ，LocalStore 只会被 Lister 的 List/Get 方法访问 。 虽然 Informer 和 Kubernetes 之间没有 resync 机制，但 Informer 内部的这两级缓存之间存在 resync 机制。 以上是 Informer 设计中的一些关键点，没有介绍一些太细节的东西，尤其对于 Informer 两级缓存还未做深入介绍。下一章节将对 Informer 详细的工作流程做一个详细介绍。 Informer 详细解析 Informer 内部主要组件 Informer 中主要包含 Controller、Reflector、DeltaFIFO、LocalStore、Lister 和 Processor 六个组件，其中 Controller 并不是 Kubernetes Controller，这两个 Controller 并没有任何联系；Reflector 的主要作用是通过 Kubernetes Watch API 监听某种 resource 下的所有事件；DeltaFIFO 和 LocalStore 是 Informer 的两级缓存；Lister 主要是被调用 List/Get 方法；Processor 中记录了所有的回调函数实例(即 ResourceEventHandler 实例)，并负责触发这些函数。 Informer 关键逻辑解析 我们以 Pod 为例，详细说明一下 Informer 的关键逻辑： Informer 在初始化时，Reflector 会先 List API 获得所有的 Pod Reflect 拿到全部 Pod 后，会将全部 Pod 放到 Store 中 如果有人调用 Lister 的 List/Get 方法获取 Pod， 那么 Lister 会直接从 Store 中拿数据 Informer 初始化完成之后，Reflector 开始 Watch Pod，监听 Pod 相关 的所有事件;如果此时 pod_1 被删除，那么 Reflector 会监听到这个事件 Reflector 将 pod_1 被删除 的这个事件发送到 DeltaFIFO DeltaFIFO 首先会将这个事件存储在自己的数据结构中(实际上是一个 queue)，然后会直接操作 Store 中的数据，删除 Store 中的 pod_1 DeltaFIFO 再 Pop 这个事件到 Controller 中 Controller 收到这个事件，会触发 Processor 的回调函数 LocalStore 会周期性地把所有的 Pod 信息重新放到 DeltaFIFO 中 Informer 总结 Informer 的内部原理比较复杂、不太容易上手，但 Informer 却是一个非常稳定可靠的 package，已被 Kubernetes 广泛使用。但是，目前关于 Informer 的文章不是很多，如果文章中有表述不正确的地方，希望各位读者悉心指正。

凤凰网历史专稿

【 大

中

小 】 【 打印 】

共有评论 2 条 有人说，晚清最后十年的核心是“激进与保守”之争，最后“激进”的革命战胜了“保守”的立宪，枪杆子逼走了皇帝，中国便向前迈进了一大步。事实上，晚清推行新政后，根本就不存在保守一说，晚清的最后十年与其说是“激进与保守”之争，倒不如说是“革新与革命”之争，最后“革命”战胜了“革新”。 推翻皇帝而没有改变专制的结构，这种革命是一种形式主义的革命。就辛亥革命而言，革命党人的“民主共和”观念固然是很浪漫主义的，但在当时只有审美价值而没有现实价值。辛亥革命最大的功绩在于赶走了皇帝，但它最大的败笔也在于此，因为它的目的本应是推翻专制结构，但却将革命的矛头集中指向了满人皇帝。 至少在前一个世纪的上半叶中，中国是个需要皇帝的国度。究竟是“革命”的效果好，还是“革新”的结果，这都需要时间去考验，一时半会恐怕难以盖棺论定。以革命的方式推翻一个王朝，赶走一个皇帝，也不一定就是件好事。至少从晚清的最后十年看来，我们对革命的喝彩声来得有点苍白，又未免有点尴尬。 历史的很多时候，播下的是龙种，收获的却是跳蚤；一味的追求尽善尽美，得到的从来就是残缺的美—可残缺又算哪门子美呢。对此，鲁迅先生曾深有感触的说，辛亥革命后，“我到街上走了一通，满眼都是白旗。然而貌虽如此，内骨子是依旧的，因为还是几个旧乡绅所组织的军政府”；“我觉得革命以前，我是做奴隶；而革命以后不多久，就受了奴隶的骗，变成了他们的奴隶了。” 作为曾经的先进代表而后又落后于时代的康有为、梁启超等人曾说，“革命不是最佳途径，共和政体也不是唯一的选择结果。当前应该以’唯一正当之手段，唯一正当之武器’，那就是改良式的君主立宪制”。他们认为，帝制时期的国民“毫无政治智识，毫无政治能力者，不知要求为何物，不知当要求为何事”，即使革命共和了，最终也不过是阿Q式的革命，到“小姐的牙床上滚上一滚”。但革命党人并不怎么认为，他们断论:“只要是中国国民，必然有共和国民之资格”；章太炎更是信心十足的说，“公理未明，即以革命明之；旧俗俱在，即以革命去之”。 很可惜的是，革命也未必是济世良方。辛亥革命一声炮响，给多灾多难的中国送来了三民主义，但革命之后的中国，问题依旧是层出不穷，那些花样不断翻新的一个又一个主义，大都是中看不中用的绣花枕头，最终还是不能解决问题。章太炎从革命家到国学大师的回归，或许能说明一点问题。 张朋园先生曾引美国学者的观点说，“一个革命运动的发生，不在专制统治的败坏或者压迫到了极点的时候，而反是统治者措意改善，压迫已经减轻、政治趋向开明之后”。此所谓，“高压者不惜增加你的痛苦，但痛苦不能构成不满；痛苦愈是加深，愈无反抗的余地”。 这个判断形容晚清的最后十年可谓十分贴切。颇具讽刺意味的是，辛亥革命的爆发并不是因为清廷专制腐败到了极点，而恰恰是因为其推行了新政和立宪的改良措施。这看起来是个悖论，却是近乎残酷的历史真实。 那清廷为什么要推行新政和立宪呢，难道是头脑一时的糊涂？ 大多数人认为，慈禧太后推行新政和立宪，不过是为了拖延时间，愚弄百姓，正如她自己所说，“立宪一事，可使我满洲朝基础永久确固，而在外革命党亦可因此消灭，候调查结局后，若果无妨碍，则必决意实行”。但是，孽种一旦诞生便自行滋长，新政和立宪措施施行后，民众的政治参与便如洪水般无法阻挡，其目标和结果决不是设计者所能完全控制的。 这最终的结果便导致了一个两难困境。新政启动之后，清廷既无力阻止变革的运行和深化，又无法有效应对变革中出现的种种问题和矛盾，但要试图回归到传统的统治秩序中去的话，那更是自寻死路。如此一来，清廷既没有勇气继续推行宪政，又无力重走老路，新政和立宪的结果反而是引火烧身后的双重煎熬，最终被由变革引发的各种合力所推翻。这种结果，不仅仅是清廷难以解开的死结，也是所有既得利益者自我改革的噩梦。 马勇先生在其著作《超越革命与改良》中提出，“现代化是一个长期而艰巨的历史过程，现代西方国家的现代化进程已充分证明，如果没有一个稳定和谐的内部秩序，任何浮躁的空喊都无济于事。社会秩序的建立与稳定并不是单单是政府的责任，全体社会成员不仅应建立起社会的共识，而且要有一个为民族根本利益而自我牺牲的勇气。” 但是，在一百年前那个社会大转型的时代，国民素质的提升不是朝夕之事，共识更是无从谈起。与此相对应的是，反是四种对立格外醒目，这便是满汉的对立、渐进与激进的对立、保守与进步的对立及革命与改良的对立。对立压倒共识，改革的艰难可想而知。 事实上，一百多年前的大多数国人未必反对皇帝，只是不能容忍满人做皇帝。按钱穆先生的说法，清代施行的完全是一种私心的政治，因为皇帝背后有全部满洲人撑腰。但清朝建国两百多年后，作为统治集团的满族贵族，他们不但不是全体国人的利益代表，在很大程度上连普通旗人的利益都不能代表。但是，为了维护他们的统治，他们总是自觉不自觉的将他们的利益泛化，把原本只是满族贵族的利益说成是全体满族人的利益，并把自己打扮成全体国民的利益代表。可惜的是，在一次又一次的丧权辱国面前，这种代表往往意味着国民的耻辱，更加激发了汉人的不满情绪。这大概就是满人的原罪了。 也许由此可以推论，假如当时是汉人做皇帝，循序渐进的推行到英国虚君式的君主立宪制，或者还有成功的可能—当然，历史是不容假设的。如果我们抛开民族的特性问题来看晚清最后十年的改良措施的话，倒也不失为一种制度上的革命。事实上，革命并非是社会政治变迁的唯一方式，清廷若以其政治权威的合法性为基础，充分运用其现有的行政组织手段进行一场自上而下的自我更新，并最终完成从传统社会向现代社会转变的话，整个国家、社会和国民都将付出更小的成本。 但1908年11月光绪与慈禧太后的去世，使得清廷的权威出现了真空。摄政王载沣的上台更是让当时的政治局势迅速走向两极化，而载沣本人又严重缺乏驾驭大局的能力和见识。本来前几年新政和立宪措施已经吊起了社会民众特别是士绅阶层的胃口，各种参政机构如谘议局、资政院等和地方自治机构也已经建立，而摄政王载沣为代表的皇族亲贵却在失去权力的恐慌中加速走向保守和偏执，其“皇族内阁”杰作更是把立宪推向了死路，也把自己推向了绝路。正所谓，庸奴误国，荼毒苍生。 被推上绝路的不仅仅是清廷和皇族亲贵，还包括那些为推进宪政而努力的立宪派。虽然立宪派曾占尽先机，风光一时，并成为当时社会的主流，但最终也只是昙花一现。随后，立宪派更在辛亥革命的隆隆炮声中沦为配角甚至所谓的“反动派”了。最终的结果是，偏师战胜了主流，革命战胜立宪。革命在推翻皇权的同时，也破坏了传统的权威，而一旦权威被破，建立一个新的权威必须要付出相应的成本，而其中主要又以暴力为手段。可叹的是，当革命成为社会共识的时候，这带来的往往是一种灾难—一个民族，如果学不会适当的妥协和有风度的对抗，那它只能在专制中沉沦。 固然，革命党人占据了道德的制高点，但这并不意味着一定会推动社会的进步。严复曾称革命后的时期是“旧者已亡，新者未立”，这种制度的混乱和失范，给国家、社会和国民，带来的何尝不是一种更大的伤害，这在后来的北洋军阀统治时期得到了充分的证明。 在国人自古以来的生存条件没有发生根本性变化的条件下，强行实行民主政治，其结果不仅不是真正意义上的民主，而且极容易地破坏了民主的名声和信誉。任何企图以观念的变化和政治体制的改变来推动社会的进步和发展，其用意虽然善良，但目的未必能实现。这就象推翻了一个皇帝便以为革命成功一样， 如果体制结构和国民的观念结构不变，那也只是赶走了王座上的皇帝，而没有赶走心中的皇帝；如果人人都想着独裁专制做皇帝，共和制度再完美也不过是空架子。 俱往矣！古老的帝国要脱去那沉积千年的厚重外壳，其痛苦的嬗变何尝不是一种死去活来的煎熬。客观的说，清末新政和立宪本已经打开了结束旧体制、开创新制度的通道，更重要的是，如果按照这种趋势走下去的话，中国沿袭了两千多年的皇权专制将发生结构性变化。这种大转型，无疑是具有革命性意义的。但历史终究是历史，它未必会符合人们的美好愿望。反对派的百般阻挠、清廷的矛盾犹豫和革命的风起云涌，终于让三百年的清王朝轰然倒塌，随之殉葬的也包括了曾经带来希望的宪政改革。 历史是容易被遗忘的，如今的人们早已忘记了那些曾经为这个古老国家的转型而努力奔波的先行者们，只因为他们没有成功的推行宪政，也未曾在历史上留下浓重的色彩。这一切，和一百年前那个飘落的宪政梦一样，都最终湮灭在滚滚的历史浪潮之中。

\ wget -qO- –no-check-certificate https://github.com/shadowsocksr/shadowsocksr/archive/$BRANCH.tar.gz | tar -xzf - -C $WORK WORKDIR $WORK/shadowsocksr-$BRANCH/shadowsocks EXPOSE $SERVER_PORT CMD python server.py -p $SERVER_PORT -k $PASSWORD -m $METHOD -O $PROTOCOL -o $OBFS -G $PROTOCOLPARAM