上个月我在钉钉群里发了一句话：「给数字员工加一个查闲忙的能力。」
十分钟后，我收到了三条消息。第一条来自 Coding Agent：「✅ 已创建 Issue #12：日程能力——支持查询闲忙。」第二条还是它：「✅ 开发完成，15/15 测试通过，已 push，CI 运行中。」第三条来自数字员工本身：「🤖 v1.3.1 已上线，日程插件已更新，随时 @我 开始工作。」
从一句话到生产环境上线，我没有打开电脑，没有写一行代码，没有手动跑一次部署。
这不是 Demo。这是我过去三周每天在用的工作方式。
上周跟一个做消费品的朋友聊天，他说：「我们去年花了大几十万买了一套 AI 选品系统，模型跑出来的 TOP 10 推荐，没有一个最后卖爆的。反而是我们产品经理在逛小红书时随手截图说『这个感觉会火』的一款，成了年度销冠。我跟老板汇报的时候都不知道怎么解释——AI 花了五十万选不出来，人刷了五分钟手机选出来了。」
我听完笑了——不是因为 AI 不行，而是因为这种故事太常见了。选股、选人、选品、做爆款内容，四件事看起来领域完全不同，但如果你仔细看它们失败的方式，几乎一模一样。
这不是 AI 暂时不行，是 问题结构决定了 AI 天然受限。
上个月，一个 CEO 朋友给我看他的 AI Executive Assistant。
这个 Assistant 每天帮他看邮件、总结会议、安排董事会、订机票、写讲话稿。用了大半年，CEO 说：「它比我的真人秘书更懂我。」
然后他问了一个问题：「我想让它也帮其他高管安排行程、协调董事会会议、统一管理行政资源。行不行？」
我说：行。但你要意识到， 你正在把它从一个分身变成一个员工。
他笑了：「不就是多服务几个人吗？能力是一样的。」
我说：能力是一样的。但 身份、权限、审计、责任归属，全部要重来。你现在的 EA 出了错，你骂它一顿就行。总裁办的 EA 出了错，谁负责？你？行政总监？还是那个 Agent 自己？
他笑不出来了。
上周，一个 FDE 给我发了条消息：「我让 Agent 帮我做一份竞品分析，它说『好的，我开始处理』，然后就消失了。两个小时后我实在忍不住，去群里问『你还在跑吗』，它回了句『是的，还在处理中』。又过了半小时，终于出来了——结果质量不错，但这两个半小时里我完全不知道它在干嘛、做到哪了、有没有卡住。」
这个场景太常见了。而且它暴露了一个大多数 Agent 平台都没认真对待的问题： 长程任务的人机交互设计。
不是模型能力的问题，不是工具调用的问题——是 **通信协议 **的问题。Agent 和人之间，缺少一套关于「什么时候说话、说什么、怎么说」的共识。
[Read More]上周一个 FDE 跟我说：「我在客户现场搭一个群聊数字员工，从建账号到调通花了两天。其中一天半在处理断线重连、图片下载、消息去重这些脏活。」
我给他看了 dingtalk-opencode-tag：下载 opencode + 装 dws + 钉钉扫码授权，三步上线。跑在免费模型上，起步成本为零。
他试了一下，十分钟就通了。然后说了一句让我印象很深的话：「这不只是一个脚手架，这是一种交付范式。」
他说得对。这个项目的意义不在于它做了什么——文本对话、图片识别、文件解读，这些功能谁都能写。意义在于它 把生产环境的脏活封装成了可复制的 Harness，让数字员工的上线门槛从「一周的工程工作」降低到「三分钟的配置」。
[Read More]上个月，一个做汽车零部件的客户给我看他们的数字员工矩阵。
七个 Agent，分布在不同的钉钉群里，覆盖销售跟进、采购审批、质检报告、供应商对账、项目进度追踪、会议纪要生成、新员工入职引导。每个 Agent 都有组织身份——有工号、有权限、有审批链、有审计日志。它们不是独立的聊天机器人，而是组织的一部分。
然后他问了一个让我想了很久的问题：「如果有人要换掉钉钉，这七个 Agent 能带走吗？」
答案是不能。不是技术上搬不走——代码和数据可以导出。而是这七个 Agent 的每一个都 深度嵌入 了钉钉的组织图谱：审批链上的层级关系、群里的权限配置、通讯录里的汇报线、上下游组织的合同状态。换一个平台，这些上下文全部归零。
这就是护城河。但它不是大多数人以为的那种护城河。
上个月，我去一个客户的运营部门看他们的周报流程。
过去的方式：周五下午，运营主管花两小时从三个系统里扒数据，手动填 Excel，写总结，发邮件给 VP。每周一早上开会讨论。
现在的方式：周一早上 8 点，数字员工「数据周报 Agent」自动从三个系统拉数据，生成周报，发到运营群里。主管花 10 分钟审核、批注，回复两个字：「OK」。
这看起来只是效率提升——从两小时变成 10 分钟。但仔细看，主语变了。
过去的周报流程，主语是 人：人去扒数据、人去写报告、人去发邮件。AI 最多是个辅助工具。
现在的周报流程，主语是 Agent：Agent 去拉数据、Agent 去生成报告、Agent 去发送。人变成了审核者和决策者。
这不是工具升级。这是工作流范式的迁移。
上个月和一个做制造业的客户聊。他们花了三个月，把内部的工艺参数、良率数据、供应商评分全部结构化，喂给了一个通用模型的 RAG 系统。效果确实好——Agent 回答的工艺问题比他们自己工程师还准，内部试用两周，业务部门已经开始依赖了。
然后 CTO 问了我一个问题：「如果我的竞品也买了同一个模型的 API，我的这些知识会不会变成模型的一部分，间接服务于他？」
我沉默了几秒。不是技术上做不到隔离——模型厂商的合同里确实写着不训练、不留存。但我没法告诉他怎么 验证 这一点。这是一个 信任问题，不是技术问题。
这个问题让我意识到：关于「模型和 Agent 的边界」的讨论，我们一直只从技术视角切入。但实际上，决定这条边界的不是能力，而是 数据主权。
[Read More]Context.dev 是一个 YC 孵化的 Web 抓取 API，帮 Agent 从任意网页提取结构化数据。它的 Quickstart 文档写得很标准：注册、拿 Key、装 SDK、写第一行代码。
但真正让我停下来的是它首页上的一个功能： Agentic Setup。
你不需要打开 Quickstart。你只需要把一行提示词粘贴到你的 Coding Agent 里：
Signup for an account & get API key with context.dev/auth.md,
then follow docs.context.dev/agent-quickstart to integrate into the codebase
Agent 会自己去注册账号、拿 API Key、读文档、检测你的项目语言、安装 SDK、写好集成代码、跑测试。整个 Quickstart 里那 5 个步骤，Agent 全自动完成了。
这不是一个 demo。这是 context.dev 推荐的首选集成方式。页面上写着两个选项：「Do it yourself」和「Let your agent do it (Recommended)」。
SDK 集成的三代演进：从读文档到写提示词
从只有大模型到完备 Harness：7 个组件缺一不可
上周我让 Agent 帮我写了一篇博客。
它从我的 wiki 里读了 5 篇历史文章做去重分析，生成初稿后自己跑了一轮对抗性评审打了 18 分，然后用 Gemini 生了一张配图、resize 到 1360px 以下、压缩成 948KB 的 PNG，再跑了一遍中文排版修复，最后 commit 推到 GitHub，等 CI 构建完成后自己验证了上线 URL。
整个过程我做了三件事：选了一个标题方向，补了两处内容，说了三次「发布」。
这套流水线跑了 4 篇博客（#290 到 #293），每篇都是这个流程。它不是 demo，是真实的生产管线。
但我回头看这套东西的时候，发现一个问题： 我搭出来的不是一个 Agent，是一个 Harness。
[Read More]