The Agentic Gap: Why a SharePoint Expert’s Excitement Stopped Me Cold

代理鸿沟：为什么一位 SharePoint 专家的兴奋让我感到寒意

I saw a SharePoint MVP’s post recently. Genuine excitement. Markdown support had landed in SharePoint. Not a joke — real, earned enthusiasm from someone who knows their domain inside out. And I get it. In the SharePoint world, that’s real progress. It matters for real users solving real problems. You don’t become an MVP without expert knowledge and public recognition. He was right to celebrate. What stopped me wasn’t his post. It was the contrast with myself — with what I used to get excited about, and what I’m working on now.

最近我看到一位 SharePoint MVP 发的帖子。那是发自内心的兴奋：SharePoint 终于支持 Markdown 了。这不是开玩笑——对于一个深谙该领域的人来说，这是一种真实且应得的热情。我完全理解。在 SharePoint 的世界里，这确实是实质性的进步。它对于解决实际问题的真实用户来说意义重大。没有深厚的专业知识和公众认可，是不可能成为 MVP 的。他庆祝得很有道理。让我停下脚步的不是他的帖子，而是我与他之间的反差——我曾经为之兴奋的事物，与我现在正在从事的工作之间的反差。

The Post I Would Have Written

我曾经会写的帖子

Eighteen months ago, I’d have written that exact post. Same enthusiasm. Same well-earned expertise. Same genuine belief that this was meaningful progress. And I’d have been right — in the world I was living in. But I’ve spent the last year backing into a different way of working. Then, over a long weekend, I sat down and built the infrastructure for agents to work autonomously — agent loops, error recovery, quality gates, the unglamorous fabric that makes autonomous code trustworthy instead of terrifying. By Sunday night, those agents had scaffolded 111 SharePoint web parts and 5 backend services. Design, build, test. All local. No human hands on the code. Three days of tooling produced months of human output. But the output wasn’t the impressive part — the steep learning curve was. The SharePoint MVP wasn’t wrong. He was just in a different conversation. And that’s the part that scared me.

十八个月前，我绝对会写出完全一样的帖子。同样的热情，同样的专业积淀，同样真诚地相信这是有意义的进步。在当时我所处的世界里，我是对的。但过去一年，我逐渐转向了一种完全不同的工作方式。在一个长周末，我坐下来构建了一套让代理（Agents）能够自主工作的架构——代理循环、错误恢复、质量门禁，这些枯燥的基础设施让自主生成的代码变得可信而非可怕。到了周日晚上，这些代理已经搭建好了 111 个 SharePoint Web 部件和 5 个后端服务。设计、构建、测试，全部在本地完成，无需人工干预。三天的工具开发产出了相当于人类数月的产出。但令人印象深刻的不是产出本身，而是那陡峭的学习曲线。那位 SharePoint MVP 并没有错，他只是处于另一个对话语境中。而这正是我感到恐惧的地方。

What YouTube Doesn’t Show You

YouTube 不会告诉你的真相

Here’s what no tutorial, TikTok, or conference talk prepares you for: the grind. Over those three days, something broke roughly every few hours. Not metaphorically — literally. You fix the macOS permissions so the agent can read files. Now it needs a gateway restart. Restart it and the model config turns out to be broken — empty model name, nothing works for two hours while you trace why. Fix that, and suddenly the build fails because the SCSS configuration is extending the wrong toolchain — it was written for Gulp, not Heft. Rewrite that, and the Yeoman scaffold generator silently ignores your CLI flags because a .yo-rc.json exists from a previous run. Build a manual template script to bypass it. Now the directories are PascalCase and your pipeline expected kebab-case. Fix that. Now C++ native modules won’t compile on Node 22. That’s before you even get to the agents looping — repeating the same three broken commands until you harden the loop detection. None of this is in a tutorial. You can’t watch a video for it. You have to live through it — hands on, late at night, no shortcut.

没有任何教程、TikTok 或会议演讲能让你为接下来的“苦差事”做好准备。在那三天里，几乎每隔几个小时就会出问题。不是比喻，是实实在在的崩溃。你修复了 macOS 权限以便代理能读取文件，结果它又需要重启网关。重启后发现模型配置坏了——模型名称为空，你花了两个小时排查原因。修复之后，构建又失败了，因为 SCSS 配置引用了错误的工具链——它是为 Gulp 写的，而不是 Heft。重写之后，Yeoman 脚手架生成器又因为之前运行留下的 .yo-rc.json 文件而悄悄忽略了你的 CLI 参数。你不得不编写一个手动模板脚本来绕过它。接着，目录变成了 PascalCase 命名，而你的流水线期望的是 kebab-case。修复它。现在 C++ 原生模块又无法在 Node 22 上编译了。这还没算上代理陷入死循环的情况——不断重复那三个错误的命令，直到你加强了循环检测机制。这些在教程里统统找不到。你无法通过看视频学会，你必须亲身经历——亲自动手，在深夜里，没有捷径。

The memory file got patched again and again. Model preferences changed. The sync method moved from a Pi server to Git-based recovery. Configs were rewritten wholesale — config.json, sass.json, tsconfig, ESLint rules, the entire pipeline script. Each fix revealed the next breakage. The pain point just moved — same problem, different file, new and creative way of failing. This is the unglamorous truth about building agent infrastructure: you’re not engineering features. You’re engineering resilience. Before it can build web parts autonomously, it has to survive the environment. Before you can trust it, it has to break in every possible way. There is no “prompt engineering” your way out of this. It’s systems engineering, and it’s dirty.

内存文件被一次次打补丁，模型偏好被不断调整。同步方式从 Pi 服务器迁移到了基于 Git 的恢复机制。配置文件被全盘重写——config.json、sass.json、tsconfig、ESLint 规则，以及整个流水线脚本。每一次修复都引出了下一个故障。痛点只是在转移——同样的问题，不同的文件，以一种崭新且富有创意的方式失败。这就是构建代理基础设施时那不光鲜的真相：你不是在设计功能，你是在设计韧性。在它能自主构建 Web 部件之前，它必须先在环境中存活下来。在你信任它之前，它必须以所有可能的方式崩溃一遍。你无法通过“提示词工程”（Prompt Engineering）来解决这些问题。这是系统工程，而且过程很脏。

Two Conversations, Same Industry

同一行业的两种对话

Here’s what I keep coming back to: these two things — celebrating markdown support and watching agents build entire applications autonomously — are happening in the same industry, on the same platform, to people with the same job title. That’s not a criticism of anyone. It’s a data point about how fast the ground is shifting. The gap isn’t between smart people and slow people. It’s between two entirely different models of what software development is becoming. In one model, we’re incrementally improving the tools we already know. In the other, the tools are learning to use themselves. And you can be a genuine expert — someone with years of deep domain knowledge, public recognition, real achievements — and still be standing in the first room while the second one exists a few doors down. I almost was.

我不断思考的是：这两件事——庆祝 Markdown 支持和看着代理自主构建整个应用程序——正发生在同一个行业、同一个平台上，甚至发生在拥有相同职位的人身上。这并不是在批评任何人，这只是一个数据点，说明了地基正在以多快的速度发生位移。这种鸿沟并非存在于聪明人和迟钝的人之间，而是存在于对“软件开发正在变成什么”的两种截然不同的认知模型之间。在一种模型中，我们是在渐进式地改进我们已知的工具；而在另一种模型中，工具正在学会使用它们自己。你可以是一位真正的专家——拥有多年深厚的领域知识、公众认可和实际成就——但你可能依然站在第一个房间里，而第二个房间就在几步之遥。我差点就是这样。

How I Almost Missed It

我是如何差点错过的

I’m not telling this story because I saw it coming. I didn’t. I backed into it. I was a SharePoint developer. Not a machine learning engineer. Not an AI researcher. A developer who spent years learning the quirks of SPFx, the SharePoint Framework, because that’s what the job demanded. What changed wasn’t my intelligence or foresight. It was a simple question: “What if I stopped prompting AI and started architecting workflows for it?” That shift — from treating AI as a smart autocomplete to treating it as a team member with a defined role, quality gates, and an audit trail — was the door I walked through. Not because I was clever. Because I was curious, and slightly lazy, and the alternative was writing web part number 112 by hand. The methodology that emerged — I now call it Works With Agents, but the name doesn’t matter — isn’t complicated. It’s just… different. Different enough that it creates a perception gap. And perception gaps are where the real opportunity lives.

我讲这个故事不是因为我预见到了未来。我没有，我是误打误撞进来的。我曾是一名 SharePoint 开发人员，不是机器学习工程师，也不是 AI 研究员。我只是一个花了多年时间学习 SPFx（SharePoint 框架）各种怪癖的开发者，因为工作需要。改变我的不是智力或远见，而是一个简单的问题：“如果我不再向 AI 发送提示词，而是开始为它架构工作流会怎样？”这种转变——从把 AI 当作智能自动补全工具，转变为把它当作拥有明确角色、质量门禁和审计追踪的团队成员——就是我跨过的那扇门。不是因为我聪明，而是因为我好奇，还有点懒，而如果不这样做，我就得亲手去写第 112 个 Web 部件。由此产生的方法论——我称之为“与代理协作”（Works With Agents），名字不重要——并不复杂。它只是……不同。这种不同足以产生认知鸿沟，而认知鸿沟正是真正机遇所在的地方。

What This Means (For All of Us)

这对我们所有人意味着什么

Here’s the uncomfortable part. The gap isn’t closing. It’s widening. The tools are getting better faster than the mental models are updating. By the time the average team lead internalises what Claude or Copilot can do today, the agents will have moved on to something else entirely. We’re not in a technology adoption curve. We’re in a fragmentation event. Three things I think are true, as of May 2026:

令人不安的部分在于：这种鸿沟并没有缩小，反而正在扩大。工具进步的速度远超我们思维模型的更新速度。当普通的团队主管真正理解 Claude 或 Copilot 今天能做什么时，代理技术可能已经进化到完全不同的阶段了。我们现在所处的不是技术采用曲线，而是一场碎片化事件。截至 2026 年 5 月，我认为以下三点是事实：

1. Your technical moat is thinner than you think. If your competitive advantage is “we build features faster,” a research loop — cron job, web search, LLM analysis, agent scaffold — can clone your feature set in a weekend. The moat is moving to compliance, trust, and domain relationships. Things that take months or years, not hours.

2. 你的技术护城河比你想象的要薄。如果你的竞争优势是“我们构建功能更快”，那么一个研究循环——定时任务、网络搜索、大模型分析、代理脚手架——可以在一个周末内克隆你的功能集。护城河正在转向合规性、信任度和领域关系。这些是需要数月或数年，而不是数小时才能建立的东西。

3. The bottleneck isn’t code generation.

4. 瓶颈不再是代码生成。