xiaohack's Blog - OAuth
type: channel
link: https://blog.xiaohack.org/tag/oauth/
items: 头像预计做第三方源迁移至本站内以及一些优化
items: GitHub Issues 集成
items: 不到百万级，看不见 MCP 的真实问题：创始人亲述这疯狂的一年

头像预计做第三方源迁移至本站内以及一些优化
type: item
date: 2026-01-28T12:07:20+08:00
description: 目前一键注册的用户头像存的是第三方 Google 或 Github 的头像 url，这会导致正常访问无法直接显示出 Google 的头像，所以做了一个迁移计划，在今天的合适实际会执行自动迁移，若迁移的头像出现问题可及时和我反馈，迁移前我会记录原头像 url 避免出现错误无法回退。另外一些优化更新： oAuth 的授权现在会显示应用作者的一些信息以及应用的域名页面方便快速访问 oAuth 应用申请和 secret 重置增加了推送提醒 修正了 oAuth 接口不安全的返回 secret 问题，已有应用的 secret 我已做了重置，上线疏忽抱歉 修正了一键排版未做金币的消耗判断 优化帖子评论分页记录，现在只要链接 p 参数变化就会记录上一次访问的分页值下次访问会直接到该分页，之前只在手动切换分页时记录 编辑金币优化，现在编辑的内容长度会与原内容长度做对比，使用差值做金币计算，新内容长度比旧内容短的话，不再消耗金币 图片的显示增加了宽度像素配置 各位更新有问题可及时反馈

GitHub Issues 集成
type: item
date: 2026-01-24T22:28:44+08:00
description: 从零构建 GitHub Issues 集成：HagiCode 的前端直连实践本文记录了在 HagiCode 平台中集成 GitHub Issues 的全过程。我们将探讨如何通过"前端直连 + 后端最小化"的架构，在保持后端轻量的同时，实现安全的 OAuth 认证与高效的 Issues 同步。背景：为什么要集成 GitHub？HagiCode 作为一个 AI 辅助开发平台，核心价值在于连接想法与实现。但在实际使用中，我们发现用户在 HagiCode 中完成了 Proposal（提案）后，往往需要手动将内容复制到 GitHub Issues 中进行项目跟踪。这带来了几个明显的痛点：工作流割裂：用户需要在两个系统之间来回切换，体验不仅不流畅，还容易导致关键信息在复制粘贴的过程中丢失。协作不便：团队其他成员习惯在 GitHub 上查看任务，无法直接看到 HagiCode 中的提案进展。重复劳动：每当提案更新，就要人工去 GitHub 更新对应的 Issue，增加不必要的维护成本。为了解决这个问题，我们决定引入 GitHub Issues Integration 功能，打通 HagiCode 会话与 GitHub 仓库的连接，实现"一键同步"。关于 HagiCode嘿，介绍一下我们正在做的东西我们正在开发 HagiCode —— 一款 AI 驱动的代码智能助手，让开发体验变得更智能、更便捷、更有趣。智能 —— AI 全程辅助，从想法到代码，让编码效率提升数倍。便捷 —— 多线程并发操作，充分利用资源，开发流程顺畅无阻。有趣 —— 游戏化机制和成就系统，让编码不再枯燥，充满成就感。项目正在快速迭代中，如果你对技术写作、知识管理或者 AI 辅助开发感兴趣，欢迎来 GitHub 看看～技术选型：前端直连 vs 后端代理在设计集成方案时，摆在我们面前的有两条路：传统的"后端代理模式"和更激进的"前端直连模式"。方案对比在传统的后端代理模式中，前端所有的请求都要先经过我们的后端，再由后端去调用 GitHub API。这虽然逻辑集中，但给后端带来了不小的负担：后端臃肿：需要编写专门的 GitHub API 客户端封装，还要处理 OAuth 的复杂状态机。Token 风险：用户的 GitHub Token 必须存储在后端数据库中，虽然可以加密，但毕竟增加了安全风险面。开发成本：需要数据库迁移来存储 Token，还需要维护一套额外的同步服务。而前端直连模式则要轻量得多。在这个方案中，我们只利用后端来处理最敏感的"密钥交换"环节（OAuth callback），获取到 Token 后，直接存在浏览器的 localStorage 里。后续创建 Issue、更新评论等操作，直接由前端发 HTTP 请求到 GitHub。对比维度后端代理模式前端直连模式后端复杂度需要完整的 OAuth 服务和 GitHub API 客户端仅需一个 OAuth 回调端点Token 管理需加密存储在数据库，有泄露风险存储在浏览器，仅用户自己可见实施成本需数据库迁移、多服务开发主要是前端工作量用户体验逻辑统一，但服务器延迟可能稍高响应极快，直接与 GitHub 交互考虑到我们要的是快速集成和最小化后端改动，最终我们采用了"前端直连模式"。这就像给浏览器发了一张"临时通行证"，拿到证之后，浏览器就可以自己去 GitHub 办事了，不需要每次都找后端管理员批准。核心设计：数据流与安全在确定架构后，我们需要设计具体的数据流。整个同步流程的核心在于如何安全地获取 Token 并高效地利用它。整体架构图整个系统可以抽象为三个角色：浏览器（前端）、HagiCode 后端、GitHub。+--------------+ +--------------+ +--------------+ | 前端 React | | 后端 | | GitHub | | | | ASP.NET | | REST API | | +--------+ | | | | | | | OAuth |--+--------> /callback | | | | | 流程 | | | | | | | +--------+ | | | | | | | | | | | | +--------+ | | +--------+ | | +--------+ | | |GitHub | +------------>Session | +----------> Issues | | | |API | | | |Metadata| | | | | | | |直连 | | | +--------+ | | +--------+ | | +--------+ | | | | | +--------------+ +--------------+ …

不到百万级，看不见 MCP 的真实问题：创始人亲述这疯狂的一年
type: item
date: 2026-01-14T17:03:43+08:00
description: 一年前，MCP 还只是一个“把模型连到工具”的开源协议；一年后，它已经冲进了一个很少有协议能抵达的位置：事实标准。 在这场一年狂飙的亲历者之一——MCP 联合创作者、核心维护者 David Soria Parrra 看来，最戏剧性的分水岭发生在四月前后：当 Sam Altman、Satya Nadella、Sundar Pichai 先后公开表态，Microsoft、Google、OpenAI 都将采用 MCP，“大客户”突然从 Cursor、VS Code 扩散到整个行业。 这一年，MCP 从本地 “桌面玩具”，一路演进到远程 server、认证机制、面向企业可用的 OAuth 重构，再到 11 月引入 long-running tasks，把深度研究、甚至 agent-to-agent 交互变成协议的一等公民。David 的总结很直接：“这一年真的非常疯狂。” 这段对谈里，David 也很坦率地复盘了 MCP 这一年的取舍：做对的，是死磕标准 HTTP；踩坑的，是把关键能力做成了‘可选项’，结果客户端大多不实现，双向能力被削掉。 更现实的问题是扩展性：规模一上来，多实例、多 Pod 下同一段交互可能打到不同机器，不得不用 Redis 之类的共享存储来“拼状态”，请求量到百万级就开始吃力：“当规模一上来，这件事一点都不好玩。”“一些公司——比如 Google、Microsoft——他们在用 MCP 的时候，规模已经大到我不能公开具体数字，但可以说是百万级请求。到了这个量级，这就真的成了一个问题。” 以下是播客内容整理，略有删节：MCP 的一年：从发布到行业事实标准 主持人：要不你先简单讲讲 MCP 的发展情况，以及之前为什么决定把它捐赠给基金会？接下来我们再系统回顾 MCP 这一年的演进，然后再请基金会的其他负责人加入，聊一些更宏观的内容。 David Soria Parrra（MCP Co-creator）：如果回到一年前，MCP 刚发布的时候，其实谁都没想到它会在这一年里迎来如此疯狂的增长。 老实说，这一年感觉像过了一个世纪。一开始是在感恩节和圣诞节前后，很多开发者开始自发地用 MCP 搭东西。随后，像 Cursor、VS Code 这样的“大客户”开始出现。 真正的拐点出现在四月左右——当时 Sam Altman、Satya Nadella、Sundar Pichai 等人陆续公开表示，Microsoft、Google、OpenAI 都会采用 MCP。那是一个非常明显的“分水岭”。与此同时，我们也一直在推进协议本身的演进。 最初，MCP 几乎只支持本地使用：你在桌面上跑一个 MCP server，通过本地 stdio 和客户端通信。但到了今年三月，我们开始推进“远程 MCP server”——也就是如何通过网络连接 MCP，并且第一次引入了认证机制。到了六月，我们又对这套认证方案进行了比较大的修订，尤其是为了让它真正适用于企业场景。 我们非常幸运，在三月到六月这段时间里，有真正做 OAuth 标准的行业专家，直接参与进来，帮我们把一些关键细节“拉正”。我们也在这段时间里大量投入在安全最佳实践上。 到了 11 月底，我们发布了新一轮重要版本，引入了长时间运行任务（long-running tasks）这一关键原语，用来支持深度研究类任务，甚至是 agent-to-agent 的交互。 现在的感觉是：MCP 的基础已经非常扎实了。接下来还有一两个关键原语和可扩展性问题需要解决，然后协议整体会进入一个相对稳定的阶段。 说实话，这一年真的非常疯狂。 主持人：你刚刚提到 agent-to-agent，那是不是也涉及 A2A 协议？在 Agentic AI Foundation 成立时，有没有讨论过把其他协议也纳入进来？ David：老实说，这几乎是必然会发生的讨论。我们当然讨论过市场上其他协议，比如一些支付协议之类的东西。但在决定成立基金会时，我们有两个非常明确的原则： 第一，我们想从小开始。这是 Anthropic 第一次参与开放源代码基金会，一切都是新的。我们希望先在一个相对可控的范围内学习如何把这件事做好，并且和 OpenAI、Block 一起，把基金会的节奏掌控住。 第二，在协议层面，我们非常在意“事实标准（de facto standard）”。目前来看，真正已经具备广泛采用度的协议，只有 MCP。其他协议还没有“走到那一步”。当然，如果未来某个协议发展到那个阶段，并且在功能上是互补的，我们是完全开放的。 在应用层，我们会更灵活；但在协议层，我们不希望一个基金会里同时维护五个做同一件事的通信协议。 主持人：你现在在基金会和 MCP 之间，是不是有点“戴两顶帽子”？ David：确实如此，但我主要精力仍然在 MCP 上。…