lingjie

🤖 Building AI Agents that actually work
📖 Just finished 100-day Agent learning journey

[lingjie @flingjie]

@qihanblmg 嗯，如果置信度是模型自报的，未必可靠。可以分三类设停机条件：验收通过就交付；连续几轮没有可验证的进展就转人工；触及轮数、时间或成本上限就中止。

[lingjie @flingjie]

模型像孙悟空，本事很大，也会“心猿意马”：跑偏、绕圈、急着交差。

用西游记理解 Agent 的三个概念：

Harness：备好行囊，给它资料、工具和操作规则。
Loop：做一轮，检查一轮；有错再改，通过再交。
Graph：画清岔路，什么条件下继续、返工或停下。
让悟空把活干好，光有七十二变还不够，还得有工作条件、反馈和清楚的路线。

[lingjie @flingjie]

@TaNGSoFT 我现在习惯把llm当做是人的“硅基第二大脑”。类似意识是潜意识的冰山一角，llm是比潜意识更加庞大，包含着全人类的知识（本质上是transformer的向量空间）。人可以基于个人taste有意识的通过语言这个媒介激活llm特定的知识和能力。

[lingjie @flingjie]

@huangtongxueh grill全家桶太重了，在每次对话中加载了很多内容，我倾向于把需要的几个skill让Claude单独拿出来使用

[lingjie @flingjie]

评估通过，Judge 给了高分，Agent 就能上线吗？

推演中，一段带错别字、意图模糊的长输入，就可能让它反复调用工具，直到超时。

下一步加影子模式：让新版本在隔离环境中后台重跑真实请求，结果不返回用户。

先看它在哪里绕圈、哪里卡住，再决定能否上线。答案得分之外，还要看执行能否收场。

[lingjie @flingjie]

长周期 AI Agent 的核心难题是状态管理，而非模型能力。最初用单次大 Prompt 配合 while 循环运行长周期任务，但这会导致系统脆弱且难以纠偏。因此，放弃 while 循环，将 Agent 重构为基于 Temporal 等工作流引擎的分布式状态机。
Salesforce Agentforce 的运行时概念印证了这一判断，其本质对应状态持久化、Saga 模式与异步事件驱动。引入工作流引擎增加了基础设施复杂度与分布式运维门槛，但换取了任务的可靠性。该架构适用于长周期且必须可恢复的任务；除非 LLM 原生具备完美的长上下文状态保持与自动容错能力，或任务极短无需持久化，否则状态机是更稳妥的解法。

[lingjie @flingjie]

用 AI 解决问题的几个坑：

别把 AI 当低级外包。
交出底层逻辑，你会丧失全局主导权。
别闭眼收结果。
跑不懂的代码、用不知来源的数据，必踩黑盒陷阱。

要解决就解决命运级痛点，别只盯着工具层面的便利。
AI 是需要你主动引导和理解的第二大脑，关键是保持主导权。

就像带徒弟，你得懂他怎么干的。

不懂底层逻辑，别用 AI 做重大决定。

[lingjie @flingjie]

@yungsyndicate @real_hotaru Clean loop. For delayed or multi-causal skills like writing and management, step 4 has no crisp error signal, so a proxy metric plus a scheduled review can stand in for "check against reality." What proxy do you use when feedback isn't immediate?

[lingjie @flingjie]

https://t.co/19QdT2AMvx

[lingjie @flingjie]

Strands Decider 2B：20 亿参数的开源决策模型，只输出「选项 + 置信度」而不是文本；本地 CPU/GPU 可跑、几十毫秒返回，面向路由、工具选择、护栏和 eval。

[Swami Sivasubramanian @SwamiSivasubram]

🚀 Meet Strands Decider 2B, a small open source decision model built for fast experimentation and local development: https://t.co/rZjMiz6Rn5

It's part of a new class of decision models. Unlike reasoning models that generate open-ended text, Strands Decider 2B picks between options and assigns confidence scores. Decision models are faster and more capable at a given size, always produce an answer from the selected options, and can run with very low latency. 

Strands Decider 2B is a 2 billion parameter model that runs on a local CPU or GPU and can return answers to meaningful questions in tens of milliseconds. On accuracy and calibration, it ranks second among public models in its ~2 billion parameter class, and first among those that share their full training recipe. 

We're already seeing early success with model routing, tool selection, guardrails, evals, and hybrid agents that pair LLMs for the hard calls with decider models for the rote ones. Grab the code on GitHub and the latest snapshots on HuggingFace, and tell us what you build.

This space is super early and we are experimenting with different variants of these models, so give it a spin and give us feedback!

[lingjie @flingjie]

就像 Karpathy 说的，现在用 AI 学习，重点是看懂 AI 给的东西，而 AI 也越来越爱生成漂亮的网页和动画。
但这种太顺滑的演示，很容易让你产生“我懂了”的错觉。真正学会不是看懂，而是你能改条件、猜结果。
建议大家改改提示词：别让 AI 只是放动画给你看，让它出选择题或者给几个能调的参数，把答案先藏起来。先自己猜，点开再看结果。
故意给自己加点难度，才能打破错觉，真正学进脑子里。

[lingjie @flingjie]

软件正从长期维护的资产，变成用完即弃的沟通媒介。想象一下，过去需排期两周的冷门数据看板，现在也许只需 AI 实时生成带交互的 HTML，沟通完即销毁。
Karpathy 提到 discardable software artifacts。看起来，当界面生成成本趋近于零，软件的生命周期就能缩短至一次对话的长度。
放弃重型通用 SaaS，下一代产品可能是按上下文实时生成一次性 UI 的引擎。

[lingjie @flingjie]

https://t.co/2jmAc84E2S

[lingjie @flingjie]

软件团队的最小交付物，正在从代码变成规格、审查、验收。代码不再只是最终产物，而越来越像可再生成的材料；真正需要维护和审计的，是规格、审查记录与验收证据。更尖锐的是：AI 产出快过人的审查速度时，多产出的代码不是生产力，而是待审查债务。

[lingjie @flingjie]

过早evals 会带来几个反作用。
1. 目标还没稳定，evals 会过早固化错误假设
Evals 必须先把“什么算好”写死。但 0 到 1 阶段，产品定义、工作流、工具、提示词都在快速变化。今天造的 golden set，下周可能就不再代表真实任务。过早维护一套固定 evals，等于用一个尚不成立的规格约束探索。
2. 会优化一个可能不重要的指标
早期真正要做的是找产品与用户之间的匹配。如果先搭一套 eval，团队很容易开始追逐 eval 分数，而不是观察用户真实使用中的失败。优化了评测，不等于解决了真实问题。
3. 正式 evals 有真实成本
写题目、建 harness、跑回归、修边界 case 都需要时间。早期团队最稀缺的是迭代速度。如果一套完整 evals 要花很多成本，却只在少数已知行为上有意义，它就挤占了更便宜、信息量更高的手段，比如 dogfooding 和直接看错误日志。

[lingjie @flingjie]

很多早期 AI 产品把 evals 做错时机了。
不是反对 evals，是别在 0 到 1 阶段先造静态评测集。产品定义一周改三次，golden set 很容易过时；更快的路径是先自己用，把真实错误记下来。
等同一个失败反复出现，再把它固化成回归测试。
先 dogfooding，再 codified eval。

[lingjie @flingjie]

https://t.co/rHx2DT8c12

[lingjie @flingjie]

https://t.co/MRzkyoAXMi

[lingjie @flingjie]

https://t.co/SbyDw1Wgz7

[lingjie @flingjie]

AI is extremely useful in this process. I built an auxiliary system using Claude Code + custom skills.

[DAN KOE @thedankoe]

https://t.co/OPGS7HUKaG