Yijun Xiao
34 posts
Yijun Xiao
@emptycommit
Building identity infrastructure @logto_io | https://t.co/YQnQJsgpaw Opinions from practice.
Remote Katılım Ekim 2013
249 Takip Edilen23 Takipçiler
写了个 TDD 的 skill，让 coding agent (Opus 4.6 high effort vs Codex GPT 5.3 Extra High) 采用 TDD 的方式从零开发一个复杂的小系统，明天起床看看他们干的怎么样。
主要关注能不能完成任务，能不能得到一个好的、易维护的架构。
目前 Opus 做的快一些，但 Codex 好像更能按我的要求一步步写测试，迭代，重构。
中文
思考过同样的问题，我们觉得 CLI 好，很大程度上是因为我们站在开发者角度上来思考。
MCP 作为协议，背后可以是 api，也可以是 cli。MCP 和 CLI 两者其实不冲突，问哪个好可能也是一个不存在的问题。
真正的问题应该是“我们现有的服务交付给 AI 使用时应该以什么样的形式交付”，这个问题就得取决于自己的目标用户来选择合适的了。
前几天写了一篇基于 MCP Server 为 SaaS 服务提供一个 AI 入口的 Blog，里面也有相关的权衡过程，仅供参考：
blog.logto.io/zh-CN/remote-m…
中文
我还感觉 MCP 也是条歪路，CLI 才是正道。
前几天新 setup 一台虚拟机，按照 GitHub MCP 配置文档进行复杂的配置过程中，发现 AI 居然会直接用本地的 gh 命令。
我完全不需要 GitHub MCP 了。
SkyWT@skywt2003
感觉这股 TUI 风潮真的是被 Claude Code 带歪的…… 相比正常 GUI 的体验，TUI 真的真的好烂。我觉得它不会是未来的趋势。（但 CLI 会是）
中文
Why do I see so many people dismissing MCP?
Imagine a day when, just like typing a URL in your browser to use a web app, you type an MCP server address into your AI app and instantly access a service. Isn’t that exciting?
And going further — AI agents can use your service through MCP. In this era, are we still only building products for humans?
Logto@logto_io
Sharing our hands-on experience at Logto building a Remote MCP Server for our own SaaS product in the AI era: - MCP vs Agent Skills – Real-world challenges (fragmented MCP client support, LLM misuse, secret leakage) – Production-grade MCP tool design blog.logto.io/remote-mcp-ser…
English
Yijun Xiao retweetledi
✨ Add user auth to your app with one prompt.
Logto MCP Server is a hosted MCP endpoint that lets your AI tool to inspect your project, create/configure the Logto app, and generate working integration code.
Uses MCP Authorization (powered by mcp-auth). Link in comments.
English
@JamesAI 赞同。长远来看 AI 会越来越像人，反过来，人长期和 AI 协作，被 AI 影响，也一定会越来越“AI 化”。所以去不去 “AI 味”并没有什么意义，应该去掉的是空洞无意义的内容。
中文
我曾经刻意追求过一种东西：怎么样去除生成内容里的“AI味”
现在我觉得，这个方向本身就错了。
首先，什么是 AI 味，谁来定义和判断？
其次，就算能定义，它真的重要吗？
内容的本质，我现在觉得只有两件事：
表达观点，捕获注意力。
有人觉得有 AI 味，有人觉得完全没有，还有人觉得“有一点点”。
这些判断，本来就来自不同的经验，偏好和情绪，它们不该成为表达着迭代的核心依据。
对纯粹的表达来说，
我真正需要在意的只有一件事：
我有没有把我的想法，说清楚。
对注意力的捕获来说，
我的感受甚至不重要，它本质上是一个“大数据问题”。
我只需要让 AI 根据每一次内容生成后的反馈，
不断调整、不断进化。
而两者的交点，
就是我心中的“完美表达”。
在悉尼和稀泥@JamesAI
先用 subagent 和 skills，打造了一个做内容的“实习生”，同时利用 Ralph Loop，让这个实习生成为具有狼性的，自驱型员工。 接下来就是看看这个实习生能做出点什么了。
中文
@DerekDu755 @virushuo 理解你说的意思，但准确一点说：MCP 是协议，基于它的 tools / resources / prompts 等才是“给 LLM 用的 API”
中文
因为终于同一批人承认了mcp是错误的路线，放弃吹mcp了。那需要有个新的东西吹一下。事情就这么简单。
howie.serious@howie_serious
不懂就问：为什么时间线上最近一周内铺天盖地的 skills？ （这是去年 10 月发布的功能。英文区现在也很少讨论。为什么忽然集中井喷了？） 跟字节的 coze 在一周前推出“技能”功能有关联吗？
中文
Yijun Xiao retweetledi
我花一天能写好几个 Skill，但是得花上一两周才能写一个 MCP Server （如视频，直接用平台账号登录 MCP Server，一句话集成登录功能）。因为 Skill 贴近业务，所有人都可以做，而一般只有开发者或者平台才会去做 MCP Server。
所以 Skill 更好传播，容易产出内容，也能快速用上。
但他俩其实不是一个层级的东西。MCP 提供能力（服务），Skill 对这些能力做编排。
然后因为 Skill 可以运行代码、调用命令行，对于大多数场景，依赖 MCP 提供能力的需求较少，所以很多人就说 Skill 要取代 MCP 了。
但这两者都是被需要的。
MCP 也还在发展，后续 MCP 和 Skill 结合起来也是有很大可能性的（例如给 LLM 直接返回使用自身 tools 的 Skill）。
中文
@RookieRicardoR @virushuo Skills 是 UGC（用户生成内容），每个人都能写。
MCP Server 提供服务，是基础设施，只有开发者和平台会去搭建。
生产者的数量就差了一个数量级。所以大家看到的都是 “MCP 不行了”。
中文
@virushuo Skill 更适合普通人的场景，而 MCP 也有独到的使用场景，MCP 依然是不可替代的，我在这个帖子里面写过：x.com/RookieRicardoR…
耳朵@RookieRicardoR
给刘老师补充一点我的看法，首先说结论: MCP 是服务，Skill 是 Agent SOP 编排器。 首先，大部分 MCP 能做的事 Skill 也能做，这个我很认可。 但是它俩的应用场景就出在: 什么事是 MCP 能做但是 Skill 不能做的。 举个例子: 1. 网络搜索。 2. 去 github 查代码。 3. 去 figma 获取原型设计数据。 4. 去 supbase 创建一个数据库。 前两个都是属于本地也能做，但是你大概率做不了的类型。 后两个属于本地完全不可能做，因为涉及到第三方服务数据和授权的类型。 这就是我说的 MCP 是服务，而这个服务提供了一种能力。 网络搜索是一个服务，它提供了实时访问互联网的能力，你要让你的 Agent 能搜查阅最新的资料， 总不可能在本地搭建一个搜索引擎。 获取 Figma 数据也是一个能力，但是你想获取 Figma 数据不可能不依赖 Figma 官方的 API，Figma 把它的 API 通过 MCP 的方式暴露给用户，那你就只能使用它的 MCP 服务所提供的能力。 在现在 Skill 大行其道的背景下，我们对于 MCP 的需求只存在于不可代替的服务能力上。 再把 MCP 说的简单一点，它就是一个远端 API，只有在你本地无法处理某种需求的时候，它才有用，其余的时候我们都可以使用本地 Skill 脚本来处理，更可控、更安全、更方便。
中文
从Claude Code这种架构完善，渐趋成熟的Agent出发去学Agent，其实挺不适合入门初学者，这是我过去3个月踩过的坑：
· 成熟Agent的架构是演进出来的，不是设计出来的。当看到各种神文里的Sub-Agent隔离、Memory系统、规划者架构，会本能地想全部照搬。结果就是在不确定性上叠加不确定性，系统反而更烂
· 正确的路径应该是从最小问题出发，先问自己：这个任务一个API Call能解决吗？不能的话，是需要Workflow还是对话Agent？只有当用户必须反复参与、功能多到前端会爆炸时，Agent才有意义
· 然后是工具的蜜月期，每加一个工具，Agent就聪明一点。但工具一多，上下文开始失控，这时候才需要隔离。不是一开始就拆节点，而是等到注意力被平均分散、性能持续变差时，Sub-Agent才成为必需品
· 初学者最容易犯的错误是把架构当知识去学，看到Planning with Files就想用，看到Memory系统就想加。但你不知道的是，每一层复杂度背后都有明确的触发条件。没遇到那个坑之前，那些优雅设计对整体系统来说反而是负担
从小问题开始，让需求逼着去迭代架构，这才是学Agent的正确姿势（当然，脑中现有“山”的全貌也非常重要）
中文
"只要社会还需要明确责任归属，AI 就不可能被当做最后一环。"这句没错，但是可能会变。
而且想想看，人也不能真正"承担后果"。医生误诊被吊销执照，病人也活不过来；法官被追责，被告失去的十年也回不来。
如果从现在“需要有人负责”的社会制度设计来看未来，我们会需要一个能坐牢的人，而不是“能做正确决定的 AI”。
这个机制还有 bug。例如医生为了不担责，只按诊疗指南来，哪怕指南不适合这个病人。大家都在做"不会被追责的选择"，而不是"正确的选择"。
如果有一天 AI 的判断稳定优于人类，制度演化的方向必然是改进责任制度以适配 AI，而不是坚持旧的人类责任结构。
所以可能没有什么职业是真正不会被取代的，只有能积极调整自己去适应时代变迁的人才难以被取代。
中文
有朋友问你说那么多职业都会被 AI 取代，那有什么职业不太会被 AI 所取代吗？
这个问的好，我门也从第一性原理来回答。几乎不被取代的职业，本质上肯定是，责任不可转移的，判断不可完全形式化的，并且以人类信任作为核心价值的。
听起来有点虚，所以咱们先说大家都能理解的 AI-proof 职位第一名：最终责任人（俗称背锅侠）。
因为只要社会还需要明确责任归属，AI 就不可能被当做最后一环。
代表职业为主治医生（要判断AI对不对的人），机长（随时准备手动接管），法官 （要为判例负责），刑事辩护律师（要出庭辩护），建筑总工程师（需要签字）等。
不是AI干不了这些，而是一旦出事就是大事，所以人类社会必须找到可被问责的人。
AI又不能坐牢，也没法吊销其执照，更无法承担舆论道德谴责（它也不care）。
所以 AI 只能做建议，无法做裁决。这些要做裁决，最终判断的职业会被 AI 极度增强，几乎不会被取代（话还不能说满是因为AGI有可能以后可以背锅）。
第二类是需要高维度判断的职业，属于每天都是新情况，问题完全不可预测的类型。
代表职业为顶级VC，外交官，危机公关负责人，CEO / 创始人。这些 AI 都替代不了，因为这些工作都是在不完整信息下做不可逆选择，没人知道最优解。
例如要不要裁员，要不要现在退出某个市场，要不要赌一个不确定的监管窗口。
这些决策的核心不是算力，而是判断力，风险偏好，和后果承担能力。Again，AI 可以推荐，可以算，但就是不能承担后果。
第三类是强人际信任关系型职业。因为信任（trust）是非常个人的，尤其是基于人性的 trust，而非基于技术能力的 trust。
代表职业心理咨询师，宗教人士，婚姻调节师等。人们越是在“人生关键节点”的时候，越不愿意把任务交给 AI。倒不是因为 AI 能力不如人类，而是我需要你理解我，我需要你为我负责。
最后一类是“定义问题”的职业。相比与解决问题，AI不擅长定义问题，尤其是还没有人定义过的问题。
代表职业有科学家，思想型作家，理论经济学家，和哲学家。原因很简单，AI 只能在问题被定义好之后才开始展现实力。
而谁来定义问题？谁来定义人类价值？谁来定义社会目标？谁又能来定义道德边界？这些目前都不可 AI 化。
总的来说，只要你的工作需要负责任，面对的情况每天都不一样，面向对象还就是需要“你”这个特定的人，那你在AI这波浪潮里，就是安全的（但是你可能很累）。
中文
最开始做 MCP tools 时短暂纠结过这些 tools 要怎么设计，但其实就两个点：
1. 如果是通过 MCP Server 直接使用服务（就像用户在 Console 上操作一样），tools 就做成业务导向的，不然五六个接口才能完成一件事情。
2. 如果是提供基础能力让别人封装，tools 就提供基础能力且保持简洁。比如文件系统 MCP Server 提供 read_file、write_file、list_directory 这些原子操作，然后各家编程 Agent 结合自己的场景来组合使用。
中文
最近开始了解 agent 开发的各种场景。感觉时间线上 MCP、Skill、Agent 内容虽多，但似乎各说各话，越讲越乱。昨天开始看 Google 的 A2A 协议，发现从 Agent 的视角很容易就能把这些概念串起来了。
Agent 需要完成特定的任务，就需要依赖一些能力，并且对这些能力做业务上封装。而连接 MCP Server 是 Agent 获得现成能力的途径之一。
当一个任务需要多个 Agent 相互协作时，就可以通过 Google 的 A2A 协议进行协作。
所以 Agent 内部做 MCP tools 的“编排”，Agent 之间通过 A2A 来做“编排”。
从 “Agent 编排 tools” 的角度来看（Agent 把这些 tools 串成任务），Skill 其实也是一种 Agent。只不过 Agent 还有一个好处是可以做到上下文隔离，例如 Claude 的 Subagents 就是在独立的上下文中运行，返回结果。而 Skill 则是按需加载上下文，还是会占用当前的上下文窗口。
Agent 上下文隔离还可以解决调用 MCP tools 时上下文爆炸的问题，Agent 内部有 LLM，把跟 MCP 交互的一堆 context 消化掉，只返回精炼的结果。
中文