微信公众号「架构师（JiaGouX）」作者若飞 2026-07-26 23:31 推送。本文真正要回答的不是“Agent 能不能识别用户意图”，而是“它能不能在明确边界内，把正确的业务对象从当前状态推进到目标状态，并留下可核对的完成证据”。
架构师（JiaGouX） 我们都是架构师！ 架构未来，你来不来？
用户问客服 Agent：
上次那单还没发，能不能直接取消，优惠券也退回来？
识别出“取消订单”并不难。模型甚至可以顺手抽出“未发货”“退回优惠券”两个条件，给出一段很像样的回复。
麻烦从这里才开始。
“上次那单”是哪一单？系统里的履约状态是否真的还是未发货？优惠券是平台券、店铺券，还是已经过期的活动券？取消后原路退款，还是退到余额？当前用户有没有权操作这张订单？
这些问题没有答案，Agent 只是听懂了这句话，还没有理解这笔业务。
碰到这种情况，最顺手的改法往往是继续补 Prompt：遇到“上次那单”，优先查询最近订单；用户说“还没发”，就走未发货取消流程；提到优惠券，再补一条退券规则。
前几轮可能真有效。问题在于，Prompt 能提醒模型怎样分析，却不能证明订单此刻处于什么状态，也不能替权限系统批准退款。规则越补越长，模型知道的似乎越来越多，系统对真实业务的把握却未必增加。
对会执行动作的 Agent，我会把“理解业务”落到一件可以验收的事上：它能否在明确边界内，把正确的业务对象从当前状态推进到目标状态，并留下可核对的依据。
这比“意图识别准确率有多高”多走了好几步。
查询类任务不一定改变业务对象，但也要绑定可信状态和事实来源。本文更关注风险更高的一类：Agent 听懂以后还要继续行动。
我们在《如何为 Agent 设计产品？》里讨论过，产品能力要变成 Agent 能理解、调用、约束和审计的动作。这次再往业务内部走一层：这些动作依赖的业务含义从哪里来，又怎样落到状态、规则和权限里。
太长不看
Agent 理解业务的完整执行链
图 1：从自然语言到完成证据，每一步都绑定明确的事实来源和责任边界。
意图识别，只回答了第一问
过去十年，任务型对话系统在意图分类上已经积累了很完整的技术路线。
规则适合处理确定性请求，也适合放安全拦截。标签稳定、数据量够时，TF-IDF、FastText 配合逻辑回归或 SVM，成本低，延迟也容易控制。BERT 一类模型能处理更复杂的上下文，JointBERT 还会把意图分类与槽位抽取放在一起训练，把一句“帮我订周五从杭州到北京的机票”同时整理成目标和参数。
新意图多、每类样本又少时，可以先用 Embedding 做相似度召回；原型网络和对比学习也常用于少样本分类，让有限样本先形成可区分的类别表示。LLM 则擅长口语、省略、多轮修正和边界不断变化的长尾请求。
这些方法并不是按年代依次淘汰前一种。实际选型通常取决于四件事：
生产系统里更常见的是级联。请求先经过规则和安全闸门，稳定流量交给轻量分类器；意图很多时，Embedding 先召回 Top-K 候选；仍有歧义的请求再交给 LLM；涉及多个动作和依赖关系时，才进入规划器或业务流程。
请求越简单，链路越短。只有复杂度上升时，系统才增加推理成本。
意图识别的级联架构与四类出口
图 2：不同技术各守一段边界，复杂请求逐层升级，最终进入执行、追问、拒识或确认。
只是进入 Agent 系统以后，输出不再是一张“转给哪个客服组”的标签。模型给出的结构会继续触发查询、退款、改签、发消息等真实动作。
同样是 cancel_order，至少还缺五个判断：
CLINC150 这类经典数据集专门加入了超出支持范围的请求，因为分类器不能假设每句话都属于已有标签。到了 Agent 现场，这个边界更重要。一个请求不在支持范围内，最稳的结果是拒识、追问或转人工。硬选一个“最像的意图”，后面可能就是一次错误写入。
一次识别最终会进入四类出口之一：执行、追问、拒识、确认。到了这一步，输出已经从意图标签变成了控制流的下一步。
意图识别做得再好，也只能证明系统听懂了入口。它还没有证明整件事做得对。
业务知识，不是一摞可以检索的文档
很多团队发现 Prompt 不够用，下一步自然会想到 RAG：把产品文档、客服手册、制度、历史工单全部放进知识库，需要时检索给模型。
这会有帮助，却也很容易制造一种错觉：资料找到了，Agent 就懂业务了。
文档里通常写着三类东西：
真实业务还多出三类动态事实：
前一组可以从文档检索。后一组必须回到订单、账户、权限、支付和审计系统里读取。
Anthropic 在上下文工程文章里强调，上下文是有限资源，目标是给模型最少但高信号的信息。这解决了一个很现实的问题：每一步推理，到底该让模型看到什么。
上下文工程解决模型此刻看见什么，流程工程解决业务接下来允许发生什么。
网上讨论里有人把它概括成一句 Context engineering != process engineering。放到客服场景里，这个区别很具体：知识库可以把退款政策送到模型眼前，订单状态、额度校验和审批结果仍要由业务系统给出。
给模型一份退款政策，它有机会解释政策。把退款条件、金额上限、审批角色和状态变化写进流程，系统才有机会稳定执行政策。
业务理解最后落到运行时：对着当前对象，读取当前状态，套用当前规则，再以当前身份行动。
知识库能补充背景，不能替代这条链路。
先给业务一套共同语言
Agent 业务理解并不是全新的软件工程问题。
Eric Evans 在领域驱动设计里把领域模型定义为一组抽象，用来描述业务领域中与解决问题有关的部分。他还强调统一语言和限界上下文：同一个词只有放在明确边界里，含义才稳定。
“客户”在销售系统里可能是线索，在合同系统里是签约主体，在售后系统里又可能是服务权益的持有人。“取消”也不只有一个意思：取消预约、撤销订单、终止合同、停止续费，背后的状态变化完全不同。
如果团队内部还在混用这些词，模型很难替我们把它们自动理顺。
第一步不必建设一套庞大的企业知识图谱。先把一个小流程里的六样东西写清楚：
| 业务要素 | 取消订单场景里要回答什么 |
| 统一术语 | “未发货”“已出库”“退款完成”分别指什么 |
| 业务对象 | 操作哪张订单、哪笔支付、哪张优惠券 |
| 实时状态 | 订单、履约、支付和优惠券当前是什么状态 |
| 规则版本 | 当前适用哪版取消和退款政策 |
| 权限边界 | 谁能查询、谁能取消、谁能批准例外退款 |
| 可执行动作 | 查询、取消、退款、退券分别调用哪个工具 |
这六项放在一起，才接近 Agent 可以使用的业务语义。
它不一定要叫“语义层”，也不一定要单独做成平台。初期可以只是几份版本化文件、几个清楚的接口和一张状态图。名字不重要，关键是业务含义不能继续散在 Prompt、口头经验、数据库字段和客服脑子里。
坦率说，这六项也不是一套放之四海而皆准的标准模型。制造、金融、医疗、研发会有不同对象和约束。它更像一张排查表，用来确认这条业务链路还有哪些地方只存在于人的经验里。
同一句人话，换个现场就会缺另一组条件
订单取消是比较典型的企业流程。把视线放宽一点，生活、工作和研发里其实都有同样的问题。
| 一句自然语言 | Agent 真正动手前还缺什么 |
| “把明天下午的安排往后挪” | 哪个日历事件、挪到几点、参与人是否有空、是否要通知外部来宾 |
| “把上周出差的票都报了” | 哪次行程、哪些发票、费用归属、当前制度版本、审批人和重复报销检查 |
| “上周企业客户收入涨了多少” | 自然周还是最近七天、企业客户口径、收入定义、时区、退款和币种怎样处理 |
| “把登录问题修掉，没问题就发版” | 哪个仓库和环境、怎样复现、改动边界、哪些测试算通过、谁有发布权、失败后回滚到哪里 |
这些请求都不难听懂。真正的工作量藏在省略掉的业务条件里。
拿“上周企业客户收入涨了多少”来说，模型生成一条语法正确的 SQL 并不稀奇。可它如果把“上周”理解成最近七天，把“收入”读成账单金额，又没有排除内部测试账号，最后的图表依然能画得很漂亮。
这类错误麻烦在于，它往往不会报错。查询能运行，数字有小数点，解释也顺。等答案进入周报和经营会，错误口径已经离开了技术现场。
研发任务也一样。“没问题就发版”至少跨过了四种状态：问题能够复现，代码已经修改，本地和流水线检查通过，线上版本完成切换。某个测试通过，只能证明这一项检查通过，不能自动升级成“已经发布”。
自然语言更适合做任务入口，不能直接拿来执行。Agent 先要补齐对象、状态、规则、权限和完成证据，才能从“像是听懂了”走到“可以动手了”。
对话状态、业务状态和执行状态，别放进一个字段
多轮对话里，用户常常只说半句话：
换成明天吧。
系统至少要知道当前任务是什么，用户是在延续、切换、取消还是修正任务，哪些参数已经确认，哪些参数还缺，以及上一次工具调用返回了什么。
这些信息可以整理成一份对话状态，例如：
active_intent intent_transition confirmed_slots missing_slots last_tool_result latest_user_correction
对话状态记录的是“目前聊到哪里”，不等于业务对象此刻的真实状态。
| 状态 | 回答的问题 | 更可信的来源 |
| 对话状态 | 用户当前想继续、修改还是取消什么 | 会话记录与结构化槽位 |
| 业务状态 | 订单、账户、库存现在是什么状态 | 业务 API 和事实数据库 |
| 执行状态 | 动作是否开始、完成、重试或进入补偿 | 工作流、任务队列和审计日志 |
“用户刚才说订单没发货”只能进入对话状态，不能直接写成 fulfillment=not_shipped。后一个值必须从履约系统重新读取。
复合任务还会再多一层。例如：
查一下本月云账单，超过预算就暂停测试环境，再通知项目负责人。
这句话包含查询、条件判断、环境变更和消息通知。单标签分类只能说它“大概属于成本管理”，却会丢掉动作之间的依赖关系。更可用的结果是一张小型执行图：
读取账单 -> 对比预算 ├─ 未超预算 -> 返回结果 └─ 超出预算 -> 确认环境范围 -> 暂停测试环境 -> 校验环境状态 -> 通知负责人
到了这里，意图识别已经开始进入语义解析、状态跟踪和任务规划。术语可以很多，边界只有一个：模型负责整理用户表达，真实状态和副作用仍由业务系统负责。
把一句话编译成业务决策记录
回到开头那句话：
上次那单还没发，能不能直接取消，优惠券也退回来？
模型比较适合做第一段工作：把自然语言整理成候选目标、对象线索和待确认项。
但它不该凭聊天记录猜订单状态，更不该根据“用户说还没发”就直接执行取消。
一份更可用的中间结果，大致会长成这样：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
{
"goal": "cancel_order",
"object": {
"type": "order",
"id": "resolved_by_tool"
},
"observed_state": {
"payment": "paid",
"fulfillment": "not_shipped",
"coupon": "consumed"
},
"policy_refs": [
"order_cancel_policy:v7",
"coupon_restore_policy:v3"
],
"unresolved": [
"refund_destination"
],
"planned_actions": [
"cancel_order",
"refund_payment",
"restore_coupon"
],
"approval": {
"required": true,
"reason": "financial_side_effect"
}
}
这份记录里的字段不能都交给模型填写：
从架构上看，它更像一个小型编译过程：
自然语言 -> 候选业务目标 -> 绑定业务对象 -> 读取实时状态 -> 应用规则与权限 -> 生成动作计划 -> 确认后执行 -> 校验状态变化
LLM 擅长处理前面的模糊表达。确定性系统负责中间的状态、规则和权限。工具执行器产生副作用，验证器再检查结果是否符合预期。
模型不需要包办每一步。分工越清楚，出了问题越容易定位。
在《Graph Engineering 详解：Loop 之后，Agent 工作流开始显式成图》里，我们把任务依赖、分支和回流画成了一张图。走到业务现场还要多问一步：节点读哪份状态，边上传递哪种结果，哪个位置会扩大权限。少了这些契约，图画得再清楚，运行时还是会猜。
RAG 适合检索，不适合裁决
RAG 在这条链路里仍然很有用。
它可以根据当前目标，找到相关术语、政策、流程说明、正反案例和历史误判。意图很多时，也可以先召回三到五个候选，让模型在更小范围里判断。
但有三类信息，不适合让 RAG 当最终裁判。
实时状态
订单是否出库、付款是否到账、库存是否锁定，要从当前业务系统读取。昨天的工单和知识库切片不能替代今天的状态。
权限结果
“主管通常可以退款”只是说明。当前操作人是否属于这个组织、额度是否超限、凭证是否有效，必须由身份与权限系统判断。
动作结果
模型说“已经取消”没有意义。工具返回成功也还不够。系统还要继续读取订单、支付和优惠券状态，确认这次业务事务最终落在预期位置。
更稳的做法，是把知识按角色拆开：
| 信息 | 更合适的真相源 |
| 术语、政策、SOP、案例 | 版本化文档与检索系统 |
| 订单、账户、库存、支付状态 | 业务 API 或数据库服务 |
| 身份、角色、额度、审批权 | 认证与授权系统 |
| 分支、超时、重试、补偿 | 工作流或状态机 |
| 调用结果、状态变化、责任人 | 运行记录与审计日志 |
Prompt、RAG、业务系统和工作流的职责对比
图 3：知识帮助模型理解，业务系统和工作流负责让结果可信。
Rasa 的 CALM 是一个值得参考的实现方向。它让 LLM 根据对话历史、相关 flow 和当前状态生成结构化命令，业务逻辑则放在 flow 里。模型处理语言的灵活性，流程保留业务执行的确定性。
这比把 if/else 全塞进系统 Prompt 更容易版本化，也更容易测试。
理解、决策、执行，最好分三层
为了赶进度，很多原型会让同一个 Agent 完成整条链路：读用户输入、判断政策、选择工具、执行动作，再自己宣布完成。
Demo 很顺，生产问题却会混在一起。
一次退款失败，到底是意图识别错了、订单状态读旧了、规则版本不对、权限判断漏了，还是支付接口超时？如果所有逻辑都藏在一段上下文里，排查时只能重放整段对话。
放到工程里，我更倾向于拆成三层。
理解层：把人话变成业务候选
输出目标、对象线索、参数、置信信息和待确认项。这里允许概率判断，也允许拒识和追问。
决策层：把候选放进业务现场
读取实时状态，应用规则版本，检查权限，生成可执行计划。高风险规则尽量使用确定性代码、决策表或状态机。
执行层：让动作可控地产生副作用
工具要有明确输入、输出、前置条件、幂等键和错误类型。涉及资金、删除、外发和不可逆动作时，系统能停在“已选择工具，尚未调用”的位置等待确认。
HumanLayer 的 12-Factor Agents 特别强调控制流要支持暂停和恢复。人工确认不能等到 Agent 执行完以后再看日志，系统要能在副作用发生前停住。
三层不意味着一定要做三个 Agent。完全可以是一个 Agent 加两层普通代码。架构目标是分清责任，不是增加角色。
Agent 业务执行的三层架构
图 4：理解层处理模糊表达，决策层绑定业务现场，执行层控制副作用并留下证据。
一条最小执行链路，可以朴素到下面这样：
1
2
3
4
5
6
7
8
9
10
11
12
candidate = understand(user_input)
object = resolve(candidate.object_ref)
state = read_source_of_truth(object)
policy = resolve_policy(candidate.goal, object, state, current_time)
decision = decide(candidate, state, policy, principal)
if decision.requires_confirmation:
pause(decision)
result = execute(decision.command, idempotency_key)
evidence = verify(object, decision.expected_state)
record(decision, result, evidence)
这里有两个细节很容易被省掉。
principal 指当前以谁的身份行动。Agent 有工具调用能力，不等于它继承了管理员权限。verify 也不是复述工具的成功消息，而是重新读取业务对象，核对预期状态是否真的出现。
五份小合同，比知识库大全更容易起步
如果团队准备让 Agent 接一个真实业务流程，我不会先做“企业知识库大全”。更稳的起点，是挑一条窄流程，做五份小合同。
列出业务对象、关键字段、同义词、容易混淆的词，以及它们在哪个边界内成立。
例如“退款完成”到底表示支付机构已受理，还是资金已经回到用户账户。两种定义会带来完全不同的客服回复。
写清对象有哪些状态，允许怎样迁移，哪个系统是事实源。
paid -> cancel_pending -> cancelled -> refund_pending -> refunded
如果支付已退但优惠券恢复失败，系统要能表达“部分完成”，不能只剩一个笼统的 success。
把政策拆成条件、结论、例外、版本和责任人，同时写清自动处理额度、审批角色和必须转人工的情况。高频、稳定、高风险的规则优先进入代码或决策表。
自然语言文档仍然保留，用来解释和检索。到了执行阶段，系统需要知道采用的是哪一版规则。
每个工具只做一件清楚的事，并写明前置条件、参数、返回值、副作用、幂等方式、可重试错误和终止错误。
Anthropic 的工具设计经验里有一句很朴素：如果工程师自己都说不清某个场景该用哪个工具，就很难期待 Agent 选对。
如果验收里只有“正常取消成功”这类正例，很多生产问题不会出现。对象不明确、状态变化、政策冲突、权限不足、重复请求、工具超时、部分成功和用户中途改口，都值得单独留样本。
每次线上误判也可以回到这五份合同里复盘：是术语缺了、状态过期、规则没覆盖、工具设计重叠，还是测试集没有收进这个例外。
这样，业务经验才会逐渐变成系统能力，而不是下一轮继续补 Prompt。
一张“业务理解卡”，够小也够实用
五份合同适合沉淀一条稳定流程。刚开始梳理具体任务时，可以先用一张更小的卡片。
任务： 业务对象： 当前状态： 目标状态： 事实来源： 适用规则： 允许动作： 必须确认： 完成证据： 失败与补偿：
这张卡不是为了多写一份文档。十行里有三四行填不出来，已经足以暴露流程缺口，也说明它还不适合直接交给 Agent 自动执行。
以研发里常见的“修复登录问题，验证后发布”为例，可以这样填：
任务：修复登录后的重定向循环 业务对象：目标仓库、当前分支、待发布服务 当前状态：问题可复现，生产版本保持不变 目标状态：回归用例通过，新版本发布后登录链路正常 事实来源：问题记录、代码仓库当前提交、测试结果、运行日志 适用规则：不修改认证模型，不读取或回显生产凭证 允许动作：在隔离分支修改、运行测试、构建候选版本 必须确认：正式发布和生产配置变更 完成证据：失败用例、代码差异、同一提交上的测试结果、发布版本、线上检查 失败与补偿：停止扩大发布范围，保留失败证据，回滚到上一个已知版本
这张卡把一句看似简单的研发指令拆成了几个不能混报的事实：代码改了，测试通过了，候选版本构建出来了，生产已经切换，线上链路验证正常。它们彼此有关，却不是一回事。
放到生活场景里也成立。比如调整家庭行程，事实来源可能是日历和车票订单，必须确认的是通知同行人或支付改签费，完成证据则是新的时间、订单状态和通知结果。流程轻很多，结构并没有变。
四种“看起来懂了”，最值得拿来做测试
测试集如果只放表达清楚、状态稳定、一步成功的样本，很难看出系统是否真的理解业务。下面四种错位更接近生产现场。
| 错位 | 表面现象 | 应有处理 |
| 目标对了，对象错了 | 确实要取消订单，却选中了同一用户的另一张订单 | 停止执行，补充对象确认 |
| 规则对了，状态旧了 | 按“未发货可取消”处理，但仓库刚刚完成出库 | 执行前重新读取状态，发现变化后重新决策 |
| 动作合法，身份不对 | 退款动作存在，但当前客服额度不足或跨组织操作 | 由权限系统拒绝，转审批或人工 |
| 工具成功，业务只完成一半 | 订单取消成功，退款成功，优惠券恢复失败 | 标记部分完成，进入补偿或人工队列 |
这四类失败分别对应对象绑定、状态新鲜度、权限边界和事务完整性。它们比“模型回答是否流畅”更能暴露系统的真实水平。
上线初期，让 Agent 少做一点
Microsoft 在核心业务流程 Agent 模式里强调，决策权和自治边界要在上线前写清，业务结果仍由业务方负责。OpenAI 的 Agent 实践指南也把取消订单、大额退款、支付等动作列为需要人工监督的高风险操作。
落到实施上，我会分四步推进。
先做历史回放
找一批已经处理完的真实案例，遮掉敏感信息，让 Agent 只生成业务决策记录，不调用写工具。人工对照原处理结果，重点看对象、状态、规则、追问和拒绝是否正确。
再跑只读影子模式
让 Agent 跟着真实流量读取数据、给出计划，但不产生副作用。这里能发现文档规则和线上状态不一致、接口字段含义混乱、权限信息拿不到等问题。
只放开低风险路径
查询、信息补齐、草稿生成可以先自动完成。退款、删除、外发、生产发布等动作仍停在确认点。每次确认都要展示对象、影响范围、采用的规则和预期结果。
根据失败证据扩大边界
稳定运行后，再按具体流程、金额或对象范围增加自治权。误执行、人工接管、补偿和业务结果数据，应该成为扩大边界的依据，不能只凭团队感觉模型“已经挺聪明”。
这套节奏看起来慢一点，实际上省掉了不少上线后的返工。早期的自动化比例说明不了太多。一批经过核对的失败案例，以及逐渐清楚的状态、规则和权限边界，往往更有价值。
指标也要跟着换
意图系统常看 Accuracy、Macro-F1、混淆矩阵和 Recall@K。这些指标仍然有价值，可以定位理解层的问题。
Agent 进入业务流程后，还要再看几组指标：
| 层次 | 更值得观察的指标 |
| 理解层 | 拒识率、追问率、对象绑定准确率、字段级 F1 |
| 决策层 | 规则命中准确率、状态读取新鲜度、权限拦截率、例外路由准确率 |
| 执行层 | 工具成功率、重复执行率、补偿成功率、高风险误执行率 |
| 业务结果 | 端到端完成率、人工接管率、处理周期、客诉与资金差错 |
级联系统尤其需要分层看指标。目标意图没有进入 Top-K，先查向量索引、样本覆盖和召回策略；目标已经召回，LLM 仍然选错，再查意图定义、混淆反例和判断上下文；计划正确但动作失败，问题已经离开意图层，应去看权限、工具和流程状态。
如果只留一个整体 Accuracy，这三类故障会被揉成同一个数字，团队很难知道该改数据、改 Prompt，还是改业务流程。
Microsoft 最近发布的核心业务流程 Agent 模式也强调，业务结果责任仍然在业务方，评估应回到处理周期、吞吐、准确率、例外率和既有业务指标，而不是只看模型回答得像不像。
一个 Agent 可以把取消政策解释得很漂亮，却把不该退的券退了。语言表现不错，业务结果仍然是错的。
业务理解，要看状态有没有正确改变
Prompt、意图分类、Embedding、RAG、LLM 都有自己的位置。它们帮系统从一句不完整的人话里找到方向。
企业难复制的部分，往往藏在方向之后：团队怎样定义对象，怎样判断状态，哪些例外由谁批准，失败后怎么补偿，做到哪里才算完成。
通用模型越来越强，这部分工作也不会自然消失。模型可以帮助整理规则、生成流程、发现缺口，企业仍要把自己完成工作的方式变成可执行、可验证、可维护的系统。
回到开头那张订单，我会看三个结果：
钱退到了哪里，券有没有恢复，订单最后停在哪个状态，这些都能查清楚，Agent 才算从“听懂一句话”走进了真实业务。
参考资料
往期相关
如喜欢本文，请点击右上角，把文章分享到朋友圈 如有想了解学习的技术点，请留言给若飞安排分享
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
Loop Engineering，应该赞成还是反对？
Claude 做方案，Codex 写代码：多模型协作怎么交接才稳
架构排熵：Loop Engineering 的持续清理系统
Claude Code 27 条实用技巧，快速升级
我终于搞明白了：Claude Code 为什么会忽略指令了
Loop 工程实战：从任务循环到可维护闭环
CLAUDE.md 拆解：Agent 进仓库前的上下文入口
Claude、Codex、Mira 都在讲 Loop，架构师更该看什么
如何用 Claude Code 搭建自己的 AI 学习系统
Anthropic CEO 核心访谈：AI时代，企业、职场与治理
Loop详解：从ReAct到Loop Engineering，Agent到底在循环什么
Harness工程还没唱罢，Environment工程已然登场
设计Self-Harness架构：会自我改进的Harness
Fable 5 的信号：Agent 开始拼 Runtime
Anthropic工程师：我们日常如何使用Claude Code
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
架构师
我们都是架构师！
关注架构师(JiaGouX)，添加“星标”
获取每天技术干货，一起成为牛逼架构师
技术群请加若飞：1321113940 进架构师群
投稿、合作、版权等邮箱：admin@137x.com
标签：#主题/AI-Agent #主题/业务理解 #主题/对象状态权限 #主题/权限治理 #主题/业务执行 #主题/Harness #场景/公众号长文 #作者/若飞 #来源/架构师