Pontus

20年程序员，all in AI Agent 生产落地
不做聊天玩具，只做能干活的工作流
在做 Grado Work | 分享真实踩坑与边界设计

[Pontus @yuanyang_ai]

我做了 20 多年软件，现在重新学习一件事：怎么让 AI 真正进入生产环境。

我越来越确定，Agent 从 Demo 到 Production，难的从来不只是模型。真正难的是：

🛠️ 怎么调用真实工具
🧠 怎么管理长期记忆
🔒 怎么做权限和数据隔离
🙋‍♂️ 什么操作必须让人确认
🕸️ 怎么让几十个 Agent 长期协作而不失控

这里主要记录我自己做 Production Agent 过程中真实踩过的坑、架构判断和工程实践。

不是研究怎么让 AI 更会聊天，而是怎么让它真正干活。

正在做 Grado Work。🛠️

[Pontus @yuanyang_ai]

@lxfater 什么是古法编程？

[Pontus @yuanyang_ai]

我倒觉得这里有两个问题。
第一，我们要分清边界：编程是门手艺，而程序员是个角色。AI 真正把价格打到地板上的，是“手敲代码”这门纯体力的手艺；但这绝不意味着“软件工程师”这个把控全局架构的角色失去了价值。

第二点尤其要命。吐槽砸了几十亿 token，最后 Agent 还是交不出一个能用的项目。 这其实跟我们早年闭着眼训练神经网络其实很像：如果没有一条极其稳定的 loss（损失函数）和 eval（评估基准），你砸再多的算力，也只不过是在错误的方向上狂奔得更快而已，最后什么都收获不了。

放到 Agent Coding 的真实业务场景里，这个 Loss / Eval 是什么？ 就是 Spec（需求定义）、Tests（测试用例）、Acceptance（验收标准）以及 Parity Harness（一致性校验防线）。
没有一致性检查和验收闭环，token 再多，也可能只是让 Agent 更勤快地返工。
真正能把东西做出来的，不是多跑几轮，而是每一轮都知道自己离“对”还有多远。

[Pontus @yuanyang_ai]

Pro/Plus账号都重置了，周未还能搞几个闭环。

[Tibo @thsottiaux]

Hi Astra users. A reset and a quick update on quality issues that have been posted around.

Working with some of you, we have found and fixed the following issues:
- Some skills written for previous models were triggering too often or preventing the model from checking its work.
- An opt-in context management experiment that could cause early stops or replies to older messages. We've disabled it. Our rough estimate is that 4-5k users were affected by this experiment.
- We've also removed some badly configured engines that resulted in a measured quality degradation for a long tail of traffic flowing through them.

We’ve also made some more minor improvements and things should feel significantly better across the board. More consistent follow-through, better tracking of your latest message, and better checks on the work as it’s going through the motions.

The examples posted and all the users who worked directly with us were incredibly useful in helping fix things quickly. Always grateful for this incredible community.

And of course, a reset is also landing by midnight today.

[Pontus @yuanyang_ai]

@thsottiaux 💪

[Pontus @yuanyang_ai]

@myanTokenGeek 唉，这种时候最怕的就是把“合规问题”和“技术判断”混成一锅。该查的查、该整改的整改，合规边界该守就得守。

但不能因为舆论一紧、管理一收，就顺手把人家这几年真正做出来的模型能力和工程进步也一起否了。外行可以管边界，但别替内行判断技术到底行不行。

[Pontus @yuanyang_ai]

这个瓜最容易被误读的地方，就是有人把“蒸馏 Claude”直接等同于“国产模型就是套壳”。我觉得绝对不能这么简单粗暴地看。

国内大模型这几年从一开始的黑箱摸索，到今天把模型真正训出来、算力成本打下来、商业生态铺开，工程上的进步是实打实的。
走到今天这个节点，真正开始变得极度稀缺的，反而是高质量数据、合成推理轨迹以及具体的训练 Recipe。

所以最近蒸馏相关的事件集中冒出来，我更愿意理解为： 模型架构在业内越来越透明公开，高质量数据和工程经验开始变成新的“军火竞争”。
至于未经授权拿数据去蒸馏、甚至后台悄悄中转用户请求，那是另一笔极其严肃的合规与信任账。

技术工程的进步是一回事，数据获取的方式是否合法合规是另一回事，别把两件事强行混为一谈。

[Pontus @yuanyang_ai]

团队群里写的技术文档，看了差点被气笑：一段简单的业务逻辑，硬是给我画了一张极其抽象的“五彩斑斓复杂大图”。一问才发现，她不是不会用绘图，而是压根不知道这里到底该画什么图。

Architecture、Sequence、Flowchart、Swimlane、State Machine、Dependency Graph、Wardley Map……名字一大堆，绝大多数非专业软件工程师或者刚转架构的新人，根本搞不清什么时候该掏出哪张牌。

之前给团队推荐了 diagram-design 这个项目，里面准备了近 40 种图。但大家用起来效果依然很差，甚至因为选项变多了反而乱涂乱抹。

我反而觉得，现在全行业最缺的根本不是第 41 种图，而是在生成前端死死卡住一个 Diagram Router（图表路由器）：

把文档丢进去，先别急着画，先回答几个问题：这段内容真的需要图吗？
读者看完以后，到底应该理解的是：结构、流程、状态、数据、责任、依赖，还是比较关系？
在近 40 种图里，哪一种最适合？
为什么不是另外两个看起来也差不多的图？
如果内容已经太复杂，是不是应该拆成：总览图 + 细节图？

我临时给团队写了个小 Prompt：
阅读下面文档，不要立即画图。先判断哪些信息值得视觉化；对每一处需要视觉化的内容，从 diagram-design 支持的图形中选择最合适的一种，并说明选择理由。优先依据读者要理解的核心关系选择：结构、顺序、状态、责任、数据流、依赖、比较或战略。若表格或文字更清楚，则明确建议不要画图。若两个图都适用，只保留最能表达主轴的一种。最后输出：文档位置 / 表达目标 / 推荐图形 / 为什么选它 / 不选什么 / 建议包含的节点。

我觉得，这东西如果做成 Skill，可能比单纯“AI 帮你画漂亮图”更有用。

因为真正困难的，从来不是把图画出来。
而是先知道：这里到底该不该画，如果要画，到底该画什么图。

[Pontus @yuanyang_ai]

豆包、WorkBuddy 这类产品形态，跟真正的企业级 Harness 相比，解决的压根就不是同一个层级的问题。

在企业 Harness 的架构图里，大家很习惯把“权限”画在最右边，充当一个看起来挺体面的安全治理模块。
但真正跑起来以后，权限压根就不可能挂在“旁边”。 它就长在 Agent 的每一次算力输出、每一次跨模块调用里面。

Agent 从 Workspace 调 Skill，从 Skill 调 Tool，再去拿 Data 和 Credential，每往前走一步，都必须继续回答：
你是谁？
代表哪个租户？
这次任务授权到哪？
这份数据能不能看？
这个 Credential 能不能拿？
这一步需不需要重新找人批准？

在这条链路里，只要漏掉任何一个上下文，后面瞬间就会演变成极其危险的越权漏洞。所以，企业级harness真正难的，不只是 RBAC，也不是多加一个 Policy Engine。

而是：让 Identity / Tenant / Task / Policy Context，像血液一样贯穿整条执行链。

底层抽象出来的 Skill 确实可以无限复用。 但权限这东西，只要松一松口子，就绝对不能跟着 Skill 一起被不小心地“复用”过去。

[robotbird @robotbird01]

企业级harness平台架构

底层基于 Pi Agent，重点解决企业级权限、Skill 复用和安全可控

[Pontus @yuanyang_ai]

https://t.co/MSZkHwiVo7

[Pontus @yuanyang_ai]

Anthropic 今天爆出来的这个安全瓜，直接扯开了一层遮羞布：我们这代最早吃螃蟹的 AI 非技术用户，正在把当年早期互联网踩过的坑，一字不差地重新踩了一遍。

当年互联网刚起来的时候，大家看到一个网站填个表，身份证、电话、地址、公司信息，什么都敢往里面塞。

因为那个时候绝大多数人根本不知道：
数据到底存在哪？
谁能看到？
后台转给了谁？
留多久？
会不会被拿去做别的事情？

今天的 AI 聊天框，本质上又把这个问题重新放大了一遍。

而且比当年的网页表单更危险。
因为 AI 产品会天然鼓励你：
“多给我一点 Context，我就能更懂你。”

于是，你脑子一热开始往里面狂塞：核心业务源码、大客户资料、内部合同、生产环境日志、API Key、整套数据库架构，甚至各种压根就不该出内网的高密机密。

Anthropic 这次报告里最值得普通用户看的，恰恰就是这一点。

按它的调查，一些用户以为自己在使用某个模型，但请求实际上被转发到了 Claude；其中甚至包含企业内部代码、生产凭据和监控数据。

也就是说，你眼睛看到的是一个聊天框，但背后真正的数据链路，你可能完全不知道。

我越来越觉得，AI 时代要把 Google 当年那句快被玩坏的老话重新请回神坛： Don’t be evil.（不作恶。）

但今天它不能只是一句公司价值观。

它应该直接变成产品架构：
用户的数据到底去了哪里，要说清楚；
有没有经过第三方模型，要说清楚；
会不会保存、训练、转卖、二次利用，要说清楚；
企业数据和个人数据怎么隔离，要说清楚；
哪些动作必须获得用户明确授权，更要说清楚。

真正值得信任的 AI，不只是“聪明”。
而是它在你看不见的地方，也不拿你的信任去套利。

在行业这些规则真正成熟之前，我给普通用户最简单的一条建议还是：
聊天框不是保险柜。
凡是你不愿意有一天出现在别人服务器日志里的东西，就不要毫无防备地往里面贴。

[Pontus @yuanyang_ai]

这张图里，我反而最盯能力与权限层。企业 Harness 实践中真正难的，可能不是 Tool / Skill Runtime 做得多丰富，而是身份和权限的上下文能不能死死咬住整条 Agent 执行链。

从 User 往下，过 Workspace、过 Skill、过 Tool、过 Data、过 Credential，最后落到 Sandbox。每跳一次，都得知道：

这是谁在调用？
代表哪个组织 / Workspace？
这次 Task 被授权到哪一级？
这个 Skill 能看哪些数据？
Tool 能拿什么 Credential？
哪一步必须重新 Ask / Approval？

不然企业里一个很危险的问题就会出现：
Skill 复用了，权限也被不小心“复用”了。
最后 Credential Proxy、共享 Skill、跨项目数据源，很容易一起变成一条隐形的超级权限通道。

所以我现在愈发笃定，在企业级的 Harness 架构里： 权限压根就不是旁边可有可无挂着的一个安全外挂模块，它就该是执行链本身的骨架。

Agent 每往前走一步，都必须带着身份、租户、任务和 Policy Context 一起走。

[Pontus @yuanyang_ai]

我对一百多个 Agent 并行狂奔越来越不感兴趣。真正让我盯住的，是他们踩坑之后老老实实补上的那套 Parity Harness（一致性校验线）。

第一轮完全放权的结果非常讽刺，但也极其真实：

代码确实能跑，但 Agent 只是把 Fortran 里的祖传全局变量、GOTO 语句和几十年前的旧架构，原封不动地“高效复刻”到了 C++ 里。

机器确实干完了活，但“干完”这个词本身的定义，从一开始就错了。

后来这事儿真正能跑通，靠的是先把“怎样才算迁移成功”变成机器能够持续验证的标准：

原系统的输出基准线到底是什么？
哪些关键中间状态必须一致？
新旧系统的数值偏差允许到什么程度？
哪些旧架构必须在迁移中真正完成现代化？
必须交出什么证据，才允许放行进入下一环？

只有先把这些验收底线划清楚，Agent 才真正有资格拿到更高阶的自治权。

所以我现在确信，在复杂 Agent Workflow 里，有个顺序不能反：

先造好“验收机器”，再放开“执行机器”。

没有可靠 Oracle（判定机 / 验收闸门）兜底的 Autonomous Agent，很多时候根本不是在提效。

它只是在用极高的执行速度，把系统里的“不确定性”一起放大。

[Pontus @yuanyang_ai]

最让我有共鸣的，反而是你这句：
Astra 做 Coding Task，提示词反而要更明确软件开发的常识和最佳实践。

现在的模型，越来越像个极其聪明、手速极快但几乎没有踩坑经验的“天才应届生”。它越是这样，Prompt 就越不该像个保姆一样从技术栈到实现细节一步步替它做决定。

真正该告诉它的，是这个软件项目自己的工程基本法：
谁还要维护这段代码？
哪些架构边界不能破？
什么结果才算完成？
哪些测试和证据必须留下？
哪些改动必须先停下来找人？

以前很多 Prompt，是为了弥补模型“不会写”。

现在模型越来越强以后，真正留下来的反而应该是那些约束它别乱写、别写坏、别只顾眼前跑通的东西。

所以我现在觉得：
模型越强，“怎么写”越可以删；
“为什么这么写、什么不能破”反而越要写清楚。

到这一步，AGENTS.md / Rules / Gates 已经不像提示词了，更像一个项目自己的“工程制度”。

[Pontus @yuanyang_ai]

以前软件工程最贵的是“实现”。AI真正把软件工程师挣钱水平重新定价的，根本不是“程序员”这个岗位，而是“手敲代码”这门体力活，有点像当年的打字员。

越是在业务线里蹚深水，这种体感就越极其强烈。

以前搞研发，最烧钱、最费精力的一大块是“实现”。 产品把需求定义清楚以后，一帮人吭哧吭哧地手写 CRUD、对接口、补测试、熬夜修 Bug。
现在呢？
这段最长、最折磨人的脏活，正在被后端的 Agent 当白菜一样疯狂甩卖。

这直接逼着软件工程师岗位会两极分化：
一头：到底该解决什么问题？
另一头：机器跑出来的这玩意儿，到底能不能验收过关？

至于中间那段“把明确需求翻译成代码”的过程，已经越来越像富士康流水线上的标准件加工了。

所以我现在真正担心的，从来不是“程序员会不会消失”。
而是：

如果你的价值全部集中在“别人已经把问题定义清楚以后，我负责实现”，那 AI 正在直接进入你的基本盘。

[zzxwill @zzxwill]

跟我的悲观论断一样，软件工程师挣钱的日子不长了。

之前关注到 Anthropic 招聘乐不少经济学家，现在他们写了这个报告

我只关注 2030 得程序员会怎样，程序员属于"知识工作者"，三个情景下的结局：

Modest（温和）：AI 影响类似互联网,宏观数据里几乎看不出来。工资、就业都在历史正常范围内。

Substantial（显著）：AI 到 2030 年有能力完成一半知识工作，其中大部分可自主完成，但并未被全面采用——大多数知识工作任务仍在不用 AI 的情况下完成。知识工作岗位减少，程序员和客服坐席可能得转去电工、护士这类受 AI 影响较小的职业。知识工作者工资基本持平，其他工种工资上涨。

Extreme（极端）：AI 在绝大多数知识工作任务上比人更高效，几乎全部自主完成，且基本不为人类创造新的知识任务。知识工作岗位大幅减少，失业率升破典型衰退水平，知识工作者工资到 2030 年下跌超 10%，劳动份额从约 60% 降到 45.2%。社会整体更富，但多数知识工作者面临降薪或失业。

原文也强调了限制：有评审者认为极端情景更像思想实验而非预测，也有人质疑受 AI 影响的职业是否真会萎缩而不是增长；模型不追踪个体工作者，且未来并非注定，取决于 AI 能做什么、企业和工人如何采用、以及收益如何分配。

一句话：温和情景没事；显著情景工资停涨、部分人转行；极端情景大量失业降薪、可能要彻底改行——但极端情景本身是否会发生，连评审的经济学家都有分歧。

我自己比这更悲观。

[Pontus @yuanyang_ai]

这个补充很重要，我前面确实把系统论里的“涌现”和工程上的“自适应编排”混到一起了。整体大于部分之和当然不是以 adaptive 为前提。

我们关注的角度可能不太一样。我这里只是更关心 agentic production里的另一个问题：如果任务复杂度、成本和风险一直在变，multi-agent 的“编制”是不是也应该跟着变？
简单任务就退化成 single-agent，复杂任务再动态拆分、并行、Review、合并。
所以这里我想讨论的：不是“adaptive 才能产生涌现”，而是 multi-agent 在 Production 里，是否应该具备动态编制能力。

[Pontus @yuanyang_ai]

这三点看下来，我最深有体会的绝对是第一条：追求极其克制的简单。

现在 AI 越跑越猛，我反而有个极其强烈的体感：以后在软件工程里，最值钱的手艺早就不再是“怎么把这玩意儿敲出来”，而是眼毒地看准什么东西压根就不该做。

以前拉个团队，人力和时间成本摆在那，大家迫于预算穷，加功能时还知道收敛点。 现在倒好，后端 Agent 一挂，什么 CRUD、搭页面、补测试全成了白菜价，连架构方案都能一秒钟给你吐出十个版本。“能做”这件事，突然变得太廉价了。
但这恰恰是最凶险的坑。 因为机器干得快，脑子一热就什么破需求都往里塞；因为大模型能写，就眼睁睁看着系统的复杂度像屎山一样一层层往上叠。最后界面上挤满了一堆大干快上的功能，真正能替用户解决痛点的核心链路，可能半点都没跑通。

特别是在我们自己死磕了七年的底层 PaaS 架构里，这事儿的体感极其痛。所以我现在越来越觉得，你后面提的“砍内耗”和“盯反馈”，其实都指向同一个极其残酷的动作：取舍。
到底哪些需求必须死保，哪些烂活儿该直接砍掉？

大模型越卷，“会干活”就越不值钱。
AI 越强，“会做”越便宜；真正越来越贵的，是知道什么不该做。

[Pontus @yuanyang_ai]

说实话，如果只把 Muse 当成是去抢 ChatGPT 和 Claude 聊天框流量的竞品，那真是把 Meta 看扁了。

看完 Meta 搞出的这个 Muse，我后背发凉的根本不是它的模型有多能打，也不是那台 24 小时挂机待命的 Agent 虚拟机。

别忘了，小扎手里捏着的最恐怖的一张底牌，一直都是他的老本行：Social Graph（社交关系链）。

Facebook、IG、WhatsApp 这全家桶里沉淀下来的，根本不是几个干瘪的用户画像标签。那是你活生生的关系链、利益网，以及海量的长期行为上下文。

Personal Agent 真要往深水区里趟，光靠记住“你上次在对话框里问了啥”是绝对不够的。它必须得长出一种跑分软件根本测不出来的能力：极其毒辣的眼力见。

它得门清你到底在跟谁协作扯皮； 列表里谁是自家人，谁是惹不起的重要客户； 什么破事儿值得直接发告警打断你； 哪些杂活它可以闭着眼替你平掉，而哪些高风险的动作，必须死死卡住 Gate（闸门），乖乖跑回来等你拍板。

Meta 真正的杀招，是只要在授权和权限边界内跑通，它就能把自己攒了几十年的 Social Graph，直接打碎喂给 Agent，变成你最底层的长期 Context。

这事儿一旦真干成了，它占住的可就不再是个闲聊入口了。 而是一个极其懂你人情世故、知进退，能长期替你平事的“数字代理人”。

[Pontus @yuanyang_ai]

看到这个 4 人团队的案子，我有个极强的体感： 现在谁还单拿人头数（HC）去算一支团队的真实规模，谁就是真外行。

明面上只是 4 个工位。 一帮人还在靠自己吭哧吭哧敲键盘、跑流程、熬大夜； 另一帮人，每个人背后都拖着一排 24 小时随时待命的 Agent 和自动化流水线。

表面看都是 4 个活人，但真到了业务线上去死磕，这能砸出来的执行产能，根本就是冷兵器碰上了重火力。

所以以后去盘一个团队到底有多能打，光问“你们批了几个 HC”已经完全没有意义了。 真正该捏在手里盘算的硬指标，只有那一个：Agent Capacity（智能体产能）。

未来评估团队真实体量的核心算法，早就不再是单纯数人头了。 而是极其残酷的：活人 HC × 每个人手里捏着的 Agent Capacity。

这才是一支团队在牌桌上，真正见血封喉的战斗力底座。

[brucexu.eth @brucexu_eth]

🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯
当我知道 Hermes Agent 团队只有 3 个人，外加一个专门做 GUI 的，一共四个人，不亚于奥特曼首次体验 GPT-5，那一刻就像看到原子弹爆炸。

我知道 Hermes Agent 团队不是很大，但是我实在是没想到这么小，这得是多么恐怖的效率？？？基本上是蓝星顶级研发战力了吧。

[Pontus @yuanyang_ai]

说实话，我倒觉得最先被大模型彻底把价格打下来的，不是“程序员”这个头衔，而是“敲代码”这门手艺本身。

以前拿高薪，大量时间其实是在干体力活：手敲 CRUD、查屎山里的 Bug、捏着鼻子补测试、两头对齐改接口。 等这些脏活儿被 Agent 大批量包圆之后，“会写代码”依然重要，但它会退化成跟“会打字”一样的出厂设置，再也卖不上天价了。

未来真正能让你在牌桌上要价的，全在代码之外：
这破需求到底要解决什么问题？
系统的边界划到哪儿必须硬性切断？
Agent 闭着眼最多能跑到哪一步？
结果烂成什么样必须打回去重做（卡住验收闸门）？
线上万一跑崩了，最后谁来背锅、谁来拍板？

这两年我自己跑 AI 业务最深的体感是： AI 敲键盘的速度越快，人的核心阵地就越被迫往两头缩—— 一头是去最前面死死盯住“定义问题”，另一头是去最后面死死卡住“验收结果”。 中间那段又长又臭的执行流，全扔给机器。

所以经常老是焦虑“程序员会不会绝种”，我其实一点都不操心这个。

我真正替同行捏把汗的是： 如果你现在唯一的护城河还是把别人早就嚼烂、喂到嘴边的明确需求才能动手，当个“人肉翻译机”按部就班地翻译成代码。那你手里的那点定价权，真的撑不过大厂的下两次发版。