技术人通常沉溺于技术的本身,高估了技术本身的价值,而忽视了其它要素的重要性。
技术人也应该关注自身身心的成长和建设(比如自省复盘),看到事物的运转是由多种要素构成,重视人的重要性、团队和组织的重要性,更加重视生活本身的重要性。
所以我为大家专门梳理了这个专栏,来提升相关的认知和认知效率。
—— @pdai
技术人通常沉溺于技术的本身,高估了技术本身的价值,而忽视了其它要素的重要性。
技术人也应该关注自身身心的成长和建设(比如自省复盘),看到事物的运转是由多种要素构成,重视人的重要性、团队和组织的重要性,更加重视生活本身的重要性。
所以我为大家专门梳理了这个专栏,来提升相关的认知和认知效率。
—— @pdai
一个真正好用的 Skill,不是把步骤写得越细越好,而是让 Agent 在某个场景下“更会思考、更会选工具、更少犯常识性错误”。
很多人一提到 Skill,第一反应是:
这当然有用。
但如果你写的是一个通用场景的 Skill,比如联网、写文档、代码审查、做调研,那么把步骤写得太死,反而会把模型的上限锁住。
来源:12-Factor Agents / Factor 1(Natural Language to Tool Calls)
把“人话需求”翻译成“结构化动作”,让模型负责理解,让代码负责执行。
你跟家里人说:
这句话要真正落地,必须变成明确单据:
来源:12-Factor Agents / Factor 2(Own your prompts)
提示词是你的核心业务逻辑之一,不要完全交给黑盒框架。
你请了一个能力很强的帮手,但你只说“你看着办”。
如果你给的是明确说明书(步骤、边界、禁区、异常处理),稳定性就会高很多。
Factor 2 的意思不是“框架不能用”,而是:
来源:12-Factor Agents / Factor 3(Own your context window)
模型是“无状态函数”,它只会基于你给的上下文做判断。上下文质量,直接决定输出质量。
看病时如果只说“我不舒服”,医生只能猜。
如果你给出病历、检查单、过敏史,诊断就会更准。
上下文窗口就是给模型的“病历袋”。
来源:12-Factor Agents / Factor 4(Tools are just structured outputs)
工具调用不是魔法,本质是模型输出结构化数据,然后由确定性代码执行。
你在餐厅点菜时,给服务员的是“菜名+份数”的单子,不是自己进后厨炒。
“点菜单”是结构化输出,“后厨流程”是确定性执行。
来源:12-Factor Agents / Factor 5(Unify execution state and business state)
尽量用一条事件线程同时承载“业务发生了什么”和“流程走到哪”,减少双状态系统的复杂度。
做饭时你记一本流水账:
这本账既告诉你“饭做到哪步”,也告诉你“发生了什么事”。
不需要再单独维护一本“流程状态账”。
来源:12-Factor Agents / Factor 6(Launch/Pause/Resume with simple APIs)
智能体要像标准任务系统一样可管理:启动、查询、暂停、恢复都要有清晰 API。
炖汤不是必须一直守着火。你可以:
智能体也应支持这样“可中断、可续跑”的节奏。
来源:12-Factor Agents / Factor 7(Contact humans with tool calls)
“请求人工介入”也要做成结构化工具调用,而不是模型随口说一句。
社区办事时,工作人员给你的不是“你看着办”,而是标准表单:
这就是结构化协作。
LLM 在“输出自然语言”还是“输出 JSON”之间,经常是一开始就做高风险选择。
一种可实验策略是:让模型尽量总是输出结构化对象,用 intent 区分不同动作。
来源:12-Factor Agents / Factor 8(Own your control flow)
控制流(循环、分支、暂停、重试、升级)必须由确定性代码掌控,不能交给模型随意决定。
导航会建议“右转”,但方向盘和刹车必须在你手里。
遇到施工、堵车、危险路段,你得自己决定绕路还是停车。